頻繁に変更されるスキーマでのSQL Server変更データキャプチャの使用

構築中の新しいサブシステムでSQL Server変更データキャプチャを有効にすることを検討しています。

それは本当に必要なわけではありませんが、完全な履歴追跡可能性を求められており、CDCは最小限の労力でこの要件をうまく解決します。

私たちはアジャイル開発プロセスに従っています。つまり、この場合、新しい列の追加、他の列へのデータの移動など、データベーススキーマに頻繁に変更を加えます。

テーブルを作成し、そのテーブルに対してCDCを有効にしてから、新しい列をテーブルに追加する小さなテストを行いました。新しい列への変更は、CDCテーブルに登録されません。

CDCテーブルを新しいスキーマに更新するメカニズムはありますか。また、データベーススキーマを移行するときに、キャプチャされたデータを処理するためのベストプラクティスはありますか？

最近、CDCについても検討を始めました。私はこの問題の専門家ではありませんが、あなたの質問にはいくつか答えがあると思います。

ほとんどの場合、CDCは完全に追跡可能な履歴という目標を達成するのに役立ちますが、それがすべての方法で達成できるとは思いません。

最初に：

データベーススキーマを頻繁に変更します... CDCテーブルを新しいスキーマに更新するメカニズムはありますか

そして、これはCDCがあなたを失敗させると私が思うところです。「変更追跡のオーバーヘッドについて」セクションのMSDNドキュメントでは、スキーマの変更が追跡されないことは明らかです。たとえば、次のようにAlter Table Add Column：

変更追跡テーブルに新しい列が追加された場合、列の追加は追跡されません。新しい列に加えられた更新と変更のみが追跡されます。

Drop Column もう少し複雑です。

ただし、DBスクリプトを使用してスキーマを変更する必要があるため、ここで必ずしもCDCに依存する必要はありません。これにより、QAスキーマとプロダクションスキーマの間で一貫性を保つことができます。また、QAへの変更はスクリプトで実行する必要があります。これにより、まったく同じ変更を製品に適用できます。これらのスクリプトからスキーマの変更を抽出することはそれほど難しくありません。これは、履歴の「時間」ディメンションが実際の時間ではなくバージョンによって駆動されることを意味しますが、最終結果は同じになります。

まだ持っていない場合は、データベーススキーマのバージョンを追跡するためのテーブルを作成します。次に、そのデータベーススキーマバージョンテーブルをCDCの下に配置して、特定のテーブル内の微視的な変更に対してスキーマへの巨視的な変更を調整できるようにします。

私の理解では、CDCがスキーマの変更を示していなくても、新しい列に追加されたデータが表示されているはずです。また、テーブルからテーブルへのデータ移行も、CDCによって取得されます。

データベーススキーマを移行するときに、キャプチャされたデータをどのように処理するかに関するベストプラクティスはありますか？

監査と同じように扱います。それが何を調べているのか、なぜそれを調べているのか、その情報を保持する必要がある期間を理解する必要があります。 このようなタスクに関しては、スコープと保持が2つの最大のバガブーです。

CDCのレポートツールは非常に厳格であるため、変更のコンテキストを知る必要があります。「すべてを追跡する！」と言うのは簡単すぎる 結果として使用可能なものが何もない状態になります。同様に、すべての変更のコピーを保持することにより、データベースのサイズを2倍にすることができます。挿入と削除が多い高チャーンテーブルでは、天文学的な成長を遂げることになります。それ自体は悪いことではありませんが、その成長に予算をかけ、生成されたすべてのデータを調べる手段が必要です。

したがって、これにより、完全なトレーサビリティが求められる理由を理解することができます。その要件には確かに正当な理由があります。ただし、その要件を満たす必要がある理由がわかるまでは、データベースの効果的な監査を構築することはできません。

DDLトリガーを使用して列の追加を追跡できます。

CREATE TRIGGER trigger_name
ON { ALL SERVER | DATABASE }
[ WITH <ddl_trigger_option> [ ,...n ] ]
{ FOR | AFTER } { event_type | event_group } [ ,...n ]
AS { sql_statement [ ; ] [ ,...n ] |
EXTERNAL NAME < method specifier > [ ; ] }

イベントグループDDL_TABLE_EVENTSを使用して、テーブルのCREATE、DROP、またはALTERを起動できます。

ただし、エンタープライズ> 2008を使用している場合、「すべての監査機能を監査仕様に組み合わせる」ことができるため、SQL Server Auditを確認することをお勧めします。このmsdnリンクには、http：//msdn.microsoft.com/en-us/library/dd392015（v = sql.100）.aspxに関する詳細な記事があります。

CREATE SERVER AUDIT audit_name
TO { [ FILE (<file_options> [, ...n]) ] |
APPLICATION_LOG | SECURITY_LOG }
[ WITH ( <audit_options> [, ...n] ) ] }[ ; ]

<file_options>::=
{FILEPATH = 'os_file_path'
[, MAXSIZE = { max_size { MB | GB | TB } | UNLIMITED } ]
[, MAX_ROLLOVER_FILES = integer ]
[, RESERVE_DISK_SPACE = { ON | OFF } ] }

<audit_options>::=
{ [ QUEUE_DELAY = integer ]
[, ON_FAILURE = { CONTINUE | SHUTDOWN } ]
[, AUDIT_GUID = uniqueidentifier ]}

次に、サーバーまたはデータベースの仕様を作成します。

Simple-Talkには、変更データキャプチャに関する優れた記事と、CDCに関する非常に詳細なガイドがあり、MSDNのドキュメントには、要件に応じてさまざまな方法が説明されています。しかし、どちらもあなたの特定の要件に役立ちます。