Срок хранения в отслеживании изменений SQL Server 2008

Меня немного беспокоит срок хранения по умолчанию в отслеживании изменений SQL Server 2008 (который составляет 2 дня).

Это хорошая идея, чтобы установить этот период, например. 100 лет и отключить автоматическую очистку, или в будущем она укусит меня из-за чрезмерного использования хранилища и / или снижения производительности? Есть у кого опыт в этом вопросе?


person Marek Stój    schedule 05.06.2010    source источник


Ответы (1)


Если вы отключили автоматическую очистку, лучше всего периодически самостоятельно просматривать и удалять информацию об отслеживании изменений, отключая и снова включая отслеживание изменений для каждой таблицы. В противном случае да, данные отслеживания будут продолжать расти и расти.

Вы не можете запросить базовые таблицы напрямую, но вы можете просмотреть их метаданные. Следующий запрос показывает относительное количество строк:

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
comment
даже 100-байтовая строка даст вам только 100 МБ после миллиона строк, поэтому я не считаю ваш пример слишком критическим, хотя я думаю, что это может быть много, если бы он отслеживался для каждой таблицы. пожалуйста, поправьте меня, если я ошибаюсь. - person Dave Cousineau; 31.07.2011
comment
@Sahuagin: в моем случае, предполагая, что не более 10% таблицы обновляется в течение двух дней, я беру на себя 0,1 * (25/15) = 16,7% накладных расходов на хранение для отслеживания изменений. Нет, это не ужасно — для сравнения, любой индекс будет как минимум (7/15) = 46,7%. Однако бессрочное удержание — это будет стоить 166%. Кроме того, я не знаю, используют ли таблицы изменений сжатие данных, но если они этого не делают, и если моя таблица сжата, то проценты становятся намного больше. - person Peter Radocchia; 31.07.2011