cdc.<capture_instance>_CT (Transact-SQL)

適用対象: SQL Server Azure SQL Database Azure 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 データベースの変更データ キャプチャを有効にした後、更新された行に対して変更テーブルの順序が正しくない3030352サポート技術情報の記事を参照してください。 詳細については、「 CDC 機能は、SQL Server 2012、2014、2016 の最新の CU にアップグレードした後に中断する可能性がありますを参照してください。

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

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

• Timestamp 列は、 binary(8)として定義されます。

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

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

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

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

既定では、INSERT、UPDATE、WRITETEXT、または UPDATETEXT の 1 回のステートメントでキャプチャ対象列に追加できる最大サイズは、65,536 バイト (64 KB) です。 このサイズを大きくして大きな LOB データをサポートするには、 テキストサイズの最大サーバー構成オプションを構成する を使用して、より大きな最大サイズを指定します。 詳細については、「 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 行目が変更テーブルに追加されます。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)