Cdc。<>capture_instance_CT (Transact-SQL)

適用対象:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

ソース テーブルで変更データ キャプチャが有効になっているときに作成された変更テーブル。 ソース テーブルに対して実行された操作が挿入や削除の場合は、各操作について 1 行を返します。ソース テーブルに対して実行された操作が更新の場合は、各操作について 2 行を返します。 ソース テーブルが有効になっているときに変更テーブルの名前が指定されていない場合、名前が派生します。 名前の形式は cdc です。capture_instance_CT capture_instance はソース テーブルのスキーマ名、ソース テーブル名は schema_table 形式です。 たとえば、AdventureWorks サンプル データベースのテーブル Person.Address で変更データ キャプチャが有効になっている場合、派生した変更テーブル名はcdc.Person_Address_CTされます。

システム テーブルに対して直接クエリを実行しないことをお勧めします。 代わりに、 cdc.fn_cdc_get_all_changes_<capture_instance> および cdc.fn_cdc_get_net_changes_<capture_instance 関数を> 実行します。

列名 データ型 説明
__$start_lsn binary(10) 変更のコミット トランザクションに関連付けられたログ シーケンス番号 (LSN)。

同じトランザクションでコミットされたすべての変更は、同じコミット LSN を共有します。 たとえば、ソース テーブルに対する削除操作で 2 つの行が削除された場合、変更テーブルには 2 つの行が含まれます。それぞれに 同じ __$start_lsn 値が含まれます。
__$end_lsn binary(10) 単に情報を示すためだけに特定されます。 サポートされていません。 将来の互換性は保証されません。

SQL Server 2012 (11.x) では、この列は常に NULL です。
__$seqval binary(10) トランザクション ログで表される操作のシーケンス。 順序付けに使用しないでください。 代わりに、 __$command_id列を 使用します。
__$operation int 変更に関連付けられているデータ操作言語 (DML) 操作を識別します。 以下のいずれかを指定できます。

1 = 削除

2 = 挿入

3 = 更新 (古い値)

列データには、更新ステートメントを実行する前の行の値が割り当てられます。

4 = 更新 (新しい値)

列データには、更新ステートメントを実行した後の行の値が割り当てられます。
__$update_mask varbinary (128) 変更された列を識別する変更テーブルの列序数に基づくビット マスク。
<キャプチャ対象のソース テーブルの列> 多様 変更テーブルの残りの列は、キャプチャ インスタンスの作成時にキャプチャされた列として識別されたソース テーブルの列です。 キャプチャ対象列リストで列が指定されなかった場合、ソース テーブルのすべての列がこのテーブルに格納されます。
__$command_id int トランザクション内の操作の順序を追跡します。

注釈

この列は __$command_id 、バージョン 2012 から 2016 の累積的な更新プログラムで導入されました。 バージョンとダウンロードの情報については、「FIX: Microsoft SQL Server データベースの変更データ キャプチャを有効にした後、更新された行に対して変更テーブルの順序が正しくない」の KB 記事3030352を参照してください。 詳細については、「SQL Server 2012、2014、2016 の最新の CU にアップグレードした後に CDC 機能が中断する可能性がある」を参照してください。

キャプチャされた列のデータ型

このテーブルに含まれるキャプチャされた列は、対応するソース列と同じデータ型と値を持ち、次の例外があります。

  • タイムスタンプ 列は binary(8) として定義されます。

  • ID 列は int または bigint として定義されます。

ただし、これらの列の値は、ソース列の値と同じです。

ラージ オブジェクト データ型

__$operation = 1 または __$operation = 3 の場合、データ型 imagetextおよび ntext の列には常に NULL 値が割り当てられます。 更新中に列が変更されない限り、__$operation = 3 の場合、データ型 varbinary(max)、varchar(max)、または nvarchar(max) の列には NULL 値が割り当てられます。 __$operation = 1 の場合、これらの列には削除時点の値が割り当てられます。 キャプチャ インスタンスに含まれる計算列の値は常に NULL です

既定では、INSERT、UPDATE、WRITETEXT、または UPDATETEXT の 1 回のステートメントでキャプチャ対象列に追加できる最大サイズは、65,536 バイト (64 KB) です。 このサイズを大きくして、より大きな LOB データをサポートするには 、最大テキスト repl size サーバー構成オプション を使用して、より大きな最大サイズを指定します。 詳細については、「 max text repl size サーバー構成オプションの構成」を参照してください。

データ定義言語の変更

列の追加や削除など、ソース テーブルに対する DDL の変更は、 cdc.ddl_history テーブルに記録されます。 これらの変更は、変更テーブルには適用されません。 つまり、変更テーブルの定義は一定のままです。 変更テーブルに行を挿入する場合、キャプチャ プロセスでは、ソース テーブルに関連付けられているキャプチャされた列リストに表示されない列は無視されます。 キャプチャ対象列リストに指定されていた列が、ソース テーブルから既に削除されていた場合、その列には NULL 値が割り当てられます。

ソース テーブルの列のデータ型の変更は、 cdc.ddl_history テーブルにも記録されます。 ただし、この変更によって、変更テーブルの定義が修正されることはありません。 ソース テーブルに対する DDL 変更のログ レコードがキャプチャ プロセスで見つかった場合は、変更テーブルにおけるキャプチャ対象列のデータ型が変更されます。

データ型のサイズを小さくするようにソース テーブルのキャプチャされた列のデータ型を変更する必要がある場合は、次の手順を使用して、変更テーブル内の同等の列を正常に変更できるようにします。

  1. ソース テーブルで、変更する列の値を、変更後のデータ型に収まるように更新します。 たとえば、データ型を int から smallint に変更した場合、値を smallint 範囲 (-32,768 から 32,767) に収まるサイズに更新します。

  2. 変更テーブルで、同等の列に対して同じ更新操作を実行します。

  3. ソース テーブル側で新しいデータ型を指定します。 データ型の変更は、変更テーブルに正常に反映されます。

データ操作言語の変更

変更データ キャプチャが有効なソース テーブルに対して挿入、更新、および削除の操作が実行されると、それらの DML 操作のレコードがデータベース トランザクション ログに表示されます。 変更データ キャプチャ プロセスは、トランザクション ログからこれらの変更に関する情報を取得し、変更を記録するために変更テーブルに 1 行または 2 行を追加します。 エントリは、ソース テーブルにコミットされたのと同じ順序で変更テーブルに追加されます。 つまり、変更テーブル エントリのコミットは、通常、各エントリごとに実行されるのではなく、変更のグループに対して実行する必要があります。

挿入操作の結果、変更テーブルに 1 行が追加されます。削除操作の結果、変更テーブルに 1 つの行が追加されます。SQL Serverが更新を "遅延更新" として実装する場合(つまり、削除操作と挿入操作のペアとして)、更新操作の結果、変更テーブルに 2 つの行が追加されます。1 行目はキャプチャされたデータの削除を反映し、2 行目は更新されたキャプチャされたデータの挿入を反映します。SQL Server は更新プログラムを "遅延更新" として実装しません。更新操作では、更新の前にキャプチャされたデータを反映する最初の行と、更新後にキャプチャされたデータを反映する 2 行目の 2 つの行が変更テーブルに追加されます。

変更テーブル エントリ内では、 __$start_lsn 列を使用して、ソース テーブルへの変更に関連付けられているコミット LSN を記録し、 __$command_id 列を使用してトランザクション内で変更を並べ替え、 __$operation 列を使用して実行された操作を記録します。 これらのメタデータ列を組み合わせて使用すると、ソース変更のコミット順序を確実に保持できます。 キャプチャ プロセスはトランザクション ログから変更情報を取得するため、変更テーブルエントリは対応するソース テーブルの変更と同期して表示されない点に注意することが重要です。 代わりに、キャプチャ プロセスがトランザクション ログから関連の変更エントリを処理した後、対応する変更が非同期で表示されます。

挿入操作と削除操作については、更新マスクのすべてのビットが設定されます。 更新操作の場合、更新の古い行と更新された新しい行の両方の更新マスクが変更され、更新中に変更された列が反映されます。

参照

sys.sp_cdc_enable_table (Transact-SQL)
sys.sp_cdc_get_ddl_history (Transact-SQL)