chris.o.smith - Friday, February 23, 2018 3:47 PM
I wouldn't. If you were to go down the road of using undocumented methods to clean it up, I would look at the undocumented stored procedure instead as it has some additional internal functions to check what is safe to delete.
But first I would really look at the settings - mostly retention period and making sure the auto cleanup is enabled.
You can have a situation where the cleanup can't keep up with the number of transactions. There is an article about it and a query to see if you are hitting this -
Change Tracking Cleanup Limitation
That same guy has written about the undocumented stored procedure to clean up - sys.sp_flush_commit_table_on_demand. There are some other things written about that so I would search on that and read all you can. The article I first read on it (and the link above) is on the SirSQL blog -
Change Tracking Cleanup - Going Beyond Automatic
Edit - added: Here is the other blog post I was looking for where Microsoft mentions the same stored procedure and why you would want to use that, how the table is used by replication as well, etc. And how it doesn't always work...
Change Tracking (aka Syscommittab) Issues and Cleanup
The post also lists some other things to try as well. I'd look at all of those things instead of just deleting everything from that table.
Sue