I have what I would think is a very standard use case for Change Tracking in SQL Server 2012. We have an OLTP database and a separate reporting database which will be periodically updated via incremental extracts from the OLTP database. Change Tracking seems perfect for this scenario in that we only need to know which rows have been changed/deleted since the last extract - we don't need the complete history of its columns' values. The one glaring omission I see in Change Tracking is the ability to explicitly clear the history after an extract successfully executes. I know I can use CHANGE_RETENTION and AUTO_CLEANUP to have this done automatically, but what if the extract job (for whatever reason) doesn't run within the pre-determined retention period? The extract could miss out on an entire set of changes and the reporting database would be inconsistent with the OLTP db. I could set the CHANGE_RETENTION to a high value (e.g. 30 days), but then I would think that would adversely affect the performance of the CHANGETABLE function since there are more (outdated) rows to comb through to return rows >= the provided last_sync_version.
I have also read that they only way to explicitly clear these tables is via ENABLE/DISABLE change tracking for the table(s), but doing that in a live OLTP system seems incorrect and I assume that we could also miss changes that occur between the Enabling and Disabling of Change Tracking.
What is the best practice on working with Change Tracking regarding cleanup? We want to perform optimally but also need to take into account the fact that the extract job may not run as expected and don't want to lose data because we missed the retention window. Is Microsoft planning to allow for explicit cleanup in future versions?
ASR RJS