We have a large production system and implemented change tracking 8 days ago with a retention policy of 3 days. The syscommittab is currently at 332 million records and climbing. We have SQL 2008 SP1 CU 7 installed (10.0.2766.0). We temporarily changed the retention policy to 10 days but scaled it back again yesterday becuase the problem with our synchronization process was solved. We have seen no noticable change in the size of the syscommittab. How can someone reliable tell if the auto clean-up is working? (it is on)
More importantly we are seeing a very severe performance degradation on production when querying the change tracking tables. The following query a week ago ran in seconds, now it takes 15-20 minutes and climbing rapidly. The table that is being queryed has only 12 rows of data in the internal change tracking table which represents it. It is a very static table.
This Query takes 15-20 minutes to run on production:
SELECT
*FROMCHANGETABLE(CHANGES dbo.[table1], 146316152)AS cLEFTOUTERJOIN dbo.[table2]AS a
WITH
(NOLOCK)ON c.[CID]= a.[CID]AND c.[DID]= a.[DID]WHERE
(
c.SYS_CHANGE_OPERATION='D'OR(a.[CID]ISNOTNULLAND a.[DID]ISNOTNULL));
This Query takes only 43 seconds:
SELECT
*FROMCHANGETABLE(CHANGES dbo.[table1],null)AS cLEFTOUTERJOIN dbo.[table2]AS a
WITH
(NOLOCK)ON c.[CID]= a.[CID]AND c.[DID]= a.[DID]WHERE
(
c.SYS_CHANGE_OPERATION='D'OR(a.[CID]ISNOTNULLAND a.[DID]ISNOTNULL))AND SYS_CHANGE_VERSION> 146316152;
The difference in the execution plan is the first one does an index seek on syscommittab using some scaler operator in the predicate where the second FASTER query uses an index scan against syscommittab. We are contemplating going to the second syntax to perform our data extracts but are unsure where the two queries return the same result set and if not what is the difference?
Any help would be appreciated, this is quickly becoming a crisis.