Если вы отключили автоматическую очистку, лучше всего периодически самостоятельно просматривать и удалять информацию об отслеживании изменений, отключая и снова включая отслеживание изменений для каждой таблицы. В противном случае да, данные отслеживания будут продолжать расти и расти.
Вы не можете запросить базовые таблицы напрямую, но вы можете просмотреть их метаданные. Следующий запрос показывает относительное количество строк:
select
s.name as schema_name
, t.name as table_name
, (select sum(rows) from sys.partitions x where o.parent_object_id = x.object_id) as rows_in_base_table
, o.name as tracking_table
, p.rows as rows_in_tracking_table
from sys.objects o
join sys.tables t on o.parent_object_id = t.object_id
join sys.schemas s on t.schema_id = s.schema_id
join sys.partitions p on o.object_id = p.object_id
where o.name like 'change[_]tracking%'
and o.schema_id = schema_id('sys')
order by schema_name, table_name
Запустите это в своей базе данных, и вы должны получить приблизительное представление о текущих накладных расходах.
Все таблицы отслеживания изменений следуют стандартной схеме. Например:
select
c.name, c.column_id
, type_name(user_type_id) as type_name
, c.max_length, c.precision, c.scale
, c.is_nullable, c.is_identity
from sys.columns c
where object_id = (
select top 1 object_id from sys.objects o
where o.name like 'change[_]tracking%'
and o.schema_id = schema_id('sys')
)
Столбцы k_% зависят от таблицы и соответствуют первичным ключам отслеживаемой таблицы. Вы смотрите на базовые минимальные накладные расходы 18 байтов + (длина первичного ключа) на строку. Это складывается!
Например, я отслеживаю несколько тонких базовых таблиц шириной всего 15 байт с 7-байтовым составным ключом. Это делает таблицы отслеживания шириной 18+7=25 байт!
person
Peter Radocchia
schedule
29.09.2010