可能是什么原因造成了沉重的IO＆＃34;启用S​​QL Server更改跟踪时数据库中的活动？

Question

我正在做一些测试来量化SQL Server的更改跟踪功能的性能/可靠性。我有一个表t1，其中我插入了100万行，一次使用Change Tracking OFF，一次使用Change Tracking On。我正在监视syscommittab的大小，更改跟踪表的大小以及针对数据库记录的I / O.正如预期的那样，只有在“更改跟踪”为“开启”时才会填充更改跟踪表和syscommitab。而且我希望针对数据库记录的IO是＆＃34;比例＆＃34;这些表的大小。但令我惊讶的是，这些都已经过时了。针对数据库记录的IO比这两个表的大小多很多。想知道是否有人知道为什么或能给我指出解决它。我使用sys.dm_io_virtual_file_stats()来确定数据库上的IO活动以及以下查询，以确定跟踪表和syscommittab的大小。

SELECT   sct1.name as CT_schema,
    sot1.name as CT_table,
    ps1.row_count as CT_rows,
    ps1.reserved_page_count*8./1024. as CT_reserved_MB,
    sct2.name as tracked_schema,
    sot2.name as tracked_name,
    ps2.row_count as tracked_rows,
    ps2.reserved_page_count*8./1024. as tracked_base_table_MB,
    change_tracking_min_valid_version(sot2.object_id) as min_valid_version
FROM sys.internal_tables it
JOIN sys.objects sot1 on it.object_id=sot1.object_id
JOIN sys.schemas AS sct1 on
sot1.schema_id=sct1.schema_id
JOIN sys.dm_db_partition_stats ps1 on
it.object_id = ps1. object_id
and ps1.index_id in (0,1)
LEFT JOIN sys.objects sot2 on it.parent_object_id=sot2.object_id
LEFT JOIN sys.schemas AS sct2 on
sot2.schema_id=sct2.schema_id
LEFT JOIN sys.dm_db_partition_stats ps2 on
sot2.object_id = ps2. object_id
and ps2.index_id in (0,1)
WHERE it.internal_type IN (209, 210)
and (sot2.name='t1' or sot1.name='syscommittab')

我在运行查询之前检查点。

赞赏任何小费或指针。

对https://www.brentozar.com/archive/2014/06/performance-tuning-sql-server-change-tracking/的上述SQL的确认。