変更データ キャプチャを有効にすると、明らかにデータベースのパフォーマンスに影響があることを読みました。このパフォーマンスの低下は、CDC が有効になっているテーブルにのみ影響しますか、それともデータベース全体のすべてのアクションに影響しますか?
私の状況では、SSIS を使用しており、大量のデータがステージング データベースに出入りしています。システムには、変換に使用されるルックアップ テーブルもいくつかあります。これらの参照テーブルのみ (インポートされたデータではない) の変更を監査する手段として CDC を使用したいと考えています。ETL の一部として実行する主要なクエリは、これらの参照テーブルにアクセスしますが、それらを変更しないため、パフォーマンスにまだ顕著な影響があるかどうかを調べようとしています。
ありがとう
その質問に対する答えは、イエスでもあり、ノーでもあります。
いいえ
テーブルで変更データ キャプチャが有効になっている場合、関連付けられたキャプチャ インスタンスが作成され、ソース テーブルでの変更データの配布がサポートされます。キャプチャ インスタンスは、変更テーブルと最大 2 つのクエリ関数で構成されます。
追跡されていないテーブルは、データの追跡に関与していないようです。
はい、なぜなら
変更データ キャプチャの変更データのソースは、SQL Server トランザクション ログです。挿入、更新、および削除が追跡対象のソース テーブルに適用されると、それらの変更を説明するエントリがログに追加されます。ログは、変更データ キャプチャ プロセスへの入力として機能します。これにより、ログが読み取られ、変更に関する情報が追跡対象のテーブルに関連付けられている変更テーブルに追加されます。
変更のソースはトランザクション ログに由来するため、変更を配布するには、キャプチャ インスタンスがトランザクション ログを読み取って解釈する必要があります(免責事項: 私の解釈)。CDC を有効にするだけで、データベース全体のパフォーマンスに影響を与えます。
推奨事項
保管所：
- 変更データ キャプチャ アーキテクチャを計画するときは、ログ サイズとログ ボリューム I/O 操作の大幅な増加を考慮してください。
- sys.sp_cdc_enable_table でファイル グループを指定することを検討してください。
- 変更データ キャプチャ メタデータ、特に cdc.lsn_time_mappings が PRIMARY とは異なるファイル グループに配置されるように、sys.sp_cdc_enble_db を実行する前に、データベースの既定のファイル グループを変更することを検討してください。
ワークロードの動作:
- 挿入直後に行を更新する必要があるシナリオは避けてください。
- 大規模な更新トランザクションが頻繁に発生するテーブルへの変更をキャプチャするために、変更データ キャプチャを使用しないようにしてください。
データ キャプチャ パラメータを変更します。
- 常に、変更データ キャプチャによってキャプチャされる列のリストを、本当に追跡する必要がある列だけに減らしてください。
- 正味の変更のサポートが必要ない場合は、@ を 0 に設定します。
- 変更データ キャプチャがワークロードに対応できるかどうかを確認するために使用します。
- 変更データ キャプチャがワークロードに対応できない場合は、スキャン ジョブのパラメーターを変更し、スキャン ジョブを再開します。
まとめ
現在、サーバーが負荷に問題なく対応している場合、変更頻度の低いテーブルに対して CDC を有効にすることで、パフォーマンスの問題に気付くことはないでしょう。
ソース