Good Morning All,
Question: Alternate ways to cleanup syscommittab.
Situation:
An abused Change Tracking implementation established pre version upgrade and patching to (13.0.5233.0) and upon removing high transaction side-table resulted in several billion record delete, single transaction upon sys.syscommittab.
Specifically after discontinuing change tracking on the most egregious offending dataset (tens of millions of transactions daily) we found log runup to the order of a terabyte per billion records in sys.syscommittab. I believe this is a product glitch in how the table is cleaned up and was looking for suggestions beyond what is outlined in cleaning up the side table (e.g. discontinuing change tracking on the offender essentially drops the side table hence no need to clean it up. Should not side table are the "sys.change_tracking_ObjectID" tables.).
We were contemplating purging in an organized fashion (not in a single transaction as the system was doing but rather in reasonable chunks) directly the sys.syscommittab table. Specifically we would target records beyond the retention period. This is after we have performed side-table cleanup such as outlined in https://blogs.msdn.microsoft.com/sql_server_team/change-tracking-cleanup-part-1/.
To add to my question above, has anyone attempted this and if not any thought on what we might expect would be helpful.
Version: SQL Server 2016 Standard SP2 CU4 (13.0.5233.0)
Logging: Full and Mirrored.
Log runup problem has been mentioned numerous times in this and other forums. It wasn't until we had a very large log run up event that we started to dig to diagnose the problem.
Compounding Symptoms: Checkpoint blocked by "Task Scheduler" which was actually performing the syscommittab cleanup and "CtCleanupTblMetadata". The process that drove up a pair of log files to their maximum, approximately 4.1 terabytes, then rolled back. We couldn't add on additional log files to the database to mitigate the 2TB limit per file due to checkpoint being blocked by the syscommittab process.
Thank you in advance for any assistance.
Question: Alternate ways to cleanup syscommittab.
Situation:
An abused Change Tracking implementation established pre version upgrade and patching to (13.0.5233.0) and upon removing high transaction side-table resulted in several billion record delete, single transaction upon sys.syscommittab.
Specifically after discontinuing change tracking on the most egregious offending dataset (tens of millions of transactions daily) we found log runup to the order of a terabyte per billion records in sys.syscommittab. I believe this is a product glitch in how the table is cleaned up and was looking for suggestions beyond what is outlined in cleaning up the side table (e.g. discontinuing change tracking on the offender essentially drops the side table hence no need to clean it up. Should not side table are the "sys.change_tracking_ObjectID" tables.).
We were contemplating purging in an organized fashion (not in a single transaction as the system was doing but rather in reasonable chunks) directly the sys.syscommittab table. Specifically we would target records beyond the retention period. This is after we have performed side-table cleanup such as outlined in https://blogs.msdn.microsoft.com/sql_server_team/change-tracking-cleanup-part-1/.
To add to my question above, has anyone attempted this and if not any thought on what we might expect would be helpful.
Version: SQL Server 2016 Standard SP2 CU4 (13.0.5233.0)
Logging: Full and Mirrored.
Log runup problem has been mentioned numerous times in this and other forums. It wasn't until we had a very large log run up event that we started to dig to diagnose the problem.
Compounding Symptoms: Checkpoint blocked by "Task Scheduler" which was actually performing the syscommittab cleanup and "CtCleanupTblMetadata". The process that drove up a pair of log files to their maximum, approximately 4.1 terabytes, then rolled back. We couldn't add on additional log files to the database to mitigate the 2TB limit per file due to checkpoint being blocked by the syscommittab process.
Thank you in advance for any assistance.