What’s the issue?
Change Tracking is a lightweight SQL Server feature that records which rows have changed in tracked tables, but not the actual changed values. It is commonly used by applications that need to sync data to mobile clients, caches, or external systems, letting them query only the rows modified since the last synchronization. This finding flags databases where change tracking is currently enabled, which warrants review to confirm it is still needed and properly maintained.
Why is this a problem?
Change tracking is far less expensive than Change Data Capture, but it is not free. Each tracked table carries extra metadata maintenance on every insert, update, and delete, and internal change tracking tables grow over time based on retention settings. If the auto cleanup process is disabled or falls behind, these internal tables can consume substantial storage and degrade performance.
Change tracking is also often left enabled long after the original consuming application has been retired, continuing to add overhead for no benefit. Additionally, certain operations such as database restores, failovers, and version upgrades require careful handling of change tracking metadata, and a stale configuration can complicate these activities.
What should you do about this?
Identify enabled databases by querying sys.change_tracking_databases, and list the tracked tables within each database using sys.change_tracking_tables. Confirm with application owners and integration teams whether change tracking is still actively used and by which consumers. If it is no longer needed, disable it at the table level with ALTER TABLE [SchemaName].[TableName] DISABLE CHANGE_TRACKING; for each tracked table, then disable it at the database level with ALTER DATABASE [DatabaseName] SET CHANGE_TRACKING = OFF;.
If change tracking remains in use, verify the auto cleanup setting is enabled and the retention period matches your consumer’s synchronization cadence, and monitor the size of the internal side tables. Document which databases and tables use change tracking, who the consumer is, and the retention requirements, so the configuration can be reviewed and retired cleanly when no longer needed.