6

SQL Server 2008変更追跡のデフォルトの保持期間（2日）について少し心配しています。

この期間をたとえばに設定するのは良い考えですか。100年後に自動クリーンアップをオフにしますか、それとも将来、ストレージの使用量が多すぎたり、パフォーマンスが低下したりして、私を苦しめますか？誰かがその問題の経験がありますか？

4

1 に答える 1

8

自動クリーンアップをオフに設定した場合は、各テーブルの変更追跡を無効にしてから再度有効にすることで、定期的に変更追跡情報を確認して削除することをお勧めします。そうでなければ、追跡データは増え続けます。

基になるテーブルを直接クエリすることはできませんが、それらのメタデータを突くことができます。次のクエリは、相対的な行数を示しています。

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 バイトになります!

于 2010-09-29T05:00:47.740 に答える