変更データ キャプチャについて (SQL Server)About Change Data Capture (SQL Server)

適用対象:○SQL Server (2008 以降) ○Azure SQL Database (Managed Instance のみ) ×Azure SQL Data Warehouse ×Parallel Data Warehouse APPLIES TO: yesSQL Server (starting with 2008) yesAzure SQL Database (Managed Instance only) noAzure SQL Data Warehouse noParallel Data Warehouse

変更データ キャプチャは、 SQL ServerSQL Server のテーブルに対して適用された挿入、更新、削除の各アクティビティを記録して、Change data capture records insert, update, and delete activity that is applied to a SQL ServerSQL Server table. 変更の詳細を、利用しやすいリレーショナル形式で格納します。This makes the details of the changes available in an easily consumed relational format. 変更された行に対応する列情報が、その変更をターゲット環境に適用するために必要なメタデータと共にキャプチャされ、追跡対象となるソース テーブルの列構造がミラー化された変更テーブルに格納されます。Column information and the metadata that is required to apply the changes to a target environment is captured for the modified rows and stored in change tables that mirror the column structure of the tracked source tables. コンシューマーは、用意されているテーブル値関数を使用して、変更データに体系的にアクセスできます。Table-valued functions are provided to allow systematic access to the change data by consumers.

この技術の対象となるデータ コンシューマーの好例が、ETL (抽出、変換、読み込み) アプリケーションです。A good example of a data consumer that is targeted by this technology is an extraction, transformation, and loading (ETL) application. ETL アプリケーションは、 SQL ServerSQL Server のソース テーブルからデータ ウェアハウスやデータ マートに変更データをインクリメンタルに読み込みます。An ETL application incrementally loads change data from SQL ServerSQL Server source tables to a data warehouse or data mart. ソース テーブルの変更をデータ ウェアハウス内のソース テーブルの表現に反映する必要がありますが、ソースのレプリカを更新するエンド ツー エンドのテクノロジでは不適切です。Although the representation of the source tables within the data warehouse must reflect changes in the source tables, an end-to-end technology that refreshes a replica of the source is not appropriate. ここで必要となるのは、対象となる異質なデータ表現に対して適用できるように構成された変更データの確実なストリームです。Instead, you need a reliable stream of change data that is structured so that consumers can apply it to dissimilar target representations of the data. SQL ServerSQL Server の変更データ キャプチャはこの技術を提供します。change data capture provides this technology.

変更データ キャプチャのデータ フローChange Data Capture Data Flow

次の図は、変更データ キャプチャの主なデータ フローを示しています。The following illustration shows the principal data flow for change data capture.

Change data capture data flowChange data capture data flow

変更データ キャプチャの変更データのソースは SQL ServerSQL Server トランザクション ログです。The source of change data for change data capture is the SQL ServerSQL Server transaction log. 追跡対象のソース テーブルに対して挿入、更新、削除の各操作が適用されると、それらの変更を記述するエントリがこのログに追加されます。As inserts, updates, and deletes are applied to tracked source tables, entries that describe those changes are added to the log. このログは、キャプチャ プロセスへの入力として機能します。The log serves as input to the capture process. このプロセスによってログが読み取られ、変更に関する情報が、追跡対象のテーブルに関連付けられている変更テーブルに追加されます。This reads the log and adds information about changes to the tracked table's associated change table. 用意されている関数を使用すると、指定した範囲にこの変更テーブルに追加された変更を列挙できます。この情報は、フィルター処理された結果セットの形式で返されます。Functions are provided to enumerate the changes that appear in the change tables over a specified range, returning the information in the form of a filtered result set. 通常は、このフィルター処理された結果セットを使用して、アプリケーション プロセスによって外部環境のソースの表現が更新されます。The filtered result set is typically used by an application process to update a representation of the source in some external environment.

変更データ キャプチャとキャプチャ インスタンスについてUnderstanding Change Data Capture and the Capture Instance

データベース内の個々のテーブルの変更を追跡するには、まずそのデータベースで変更データ キャプチャを明示的に有効にする必要があります。Before changes to any individual tables within a database can be tracked, change data capture must be explicitly enabled for the database. これは、 sys.sp_cdc_enable_dbストアド プロシージャを使用して実行します。This is done by using the stored procedure sys.sp_cdc_enable_db. データベースを有効にした後、 sys.sp_cdc_enable_tableストアド プロシージャを使用して、ソース テーブルを追跡対象テーブルとして指定できます。When the database is enabled, source tables can be identified as tracked tables by using the stored procedure sys.sp_cdc_enable_table. テーブルに対して変更データ キャプチャを有効にすると、関連付けられたキャプチャ インスタンスが作成されます。これにより、ソース テーブルの変更データの伝播がサポートされます。When a table is enabled for change data capture, an associated capture instance is created to support the dissemination of the change data in the source table. キャプチャ インスタンスは、1 つの変更テーブルと、最大 2 つのクエリ関数で構成されます。The capture instance consists of a change table and up to two query functions. キャプチャ インスタンスの構成の詳細を記述するメタデータは、変更データ キャプチャのメタデータ テーブル ( cdc.change_tablescdc.index_columns、および cdc.captured_columns) に保持されます。Metadata that describes the configuration details of the capture instance is retained in the change data capture metadata tables cdc.change_tables, cdc.index_columns, and cdc.captured_columns. この情報を取得するには、 sys.sp_cdc_help_change_data_captureストアド プロシージャを使用します。This information can be retrieved by using the stored procedure sys.sp_cdc_help_change_data_capture.

キャプチャ インスタンスに関連付けられているオブジェクトはすべて、有効にされたデータベースの変更データ キャプチャ スキーマに作成されます。All objects that are associated with a capture instance are created in the change data capture schema of the enabled database. キャプチャ インスタンスの名前は、データベースのキャプチャ インスタンス間で重複しない有効なオブジェクト名である必要があります。The requirements for the capture instance name is that it be a valid object name, and that it be unique across the database capture instances. 既定の名前は、ソース テーブルの <スキーマ名_テーブル名> です。By default, the name is <schema name_table name> of the source table. 関連付けられている変更テーブルの名前は、キャプチャ インスタンス名の末尾に _CT を付けた名前になります。Its associated change table is named by appending _CT to the capture instance name. すべての変更のクエリを実行する関数の名前は、キャプチャ インスタンス名の先頭に fn_cdc_get_all_changes_ を付けた名前になります。The function that is used to query for all changes is named by prepending fn_cdc_get_all_changes_ to the capture instance name. キャプチャ インスタンスが net changes をサポートするように構成されている場合は、net_changes クエリ関数も作成されます。この関数の名前は、キャプチャ インスタンス名の先頭に fn_cdc_get_net_changes_ を付けた名前になります。If the capture instance is configured to support net changes, the net_changes query function is also created and named by prepending fn_cdc_get_net_changes_ to the capture instance name.

変更テーブルChange Table

変更データ キャプチャの変更テーブルの最初の 5 つの列は、メタデータ列です。The first five columns of a change data capture change table are metadata columns. これらは、記録された変更に関係する追加情報を提供します。These provide additional information that is relevant to the recorded change. 残りの列には、識別されたソース テーブルのキャプチャ対象列の名前 (および通常は型) が反映されます。The remaining columns mirror the identified captured columns from the source table in name and, typically, in type. これらの列は、ソース テーブルから収集されたキャプチャ対象列のデータを保持します。These columns hold the captured column data that is gathered from the source table.

ソース テーブルに適用された挿入または削除の各操作は、変更テーブル内の 1 つの行として表されます。Each insert or delete operation that is applied to a source table appears as a single row within the change table. 挿入操作の結果となる行のデータ列には挿入後の列の値が含まれ、The data columns of the row that results from an insert operation contain the column values after the insert. 削除操作の結果となる行のデータ列には削除前の列の値が含まれます。The data columns of the row that results from a delete operation contain the column values before the delete. 更新操作では、更新前の列の値を識別する行と更新後の列の値を識別する行の 2 つの行エントリが必要になります。An update operation requires one row entry to identify the column values before the update, and a second row entry to identify the column values after the update.

変更テーブルの各行には、変更アクティビティの解釈に使用される追加のメタデータも含まれています。Each row in a change table also contains additional metadata to allow interpretation of the change activity. __$start_lsn 列は、変更に割り当てられたコミット ログ シーケンス番号 (LSN) を識別します。The column __$start_lsn identifies the commit log sequence number (LSN) that was assigned to the change. コミット LSN では、同じトランザクション内でコミットされた変更が識別されるだけでなく、それらのトランザクションが順序付けられます。The commit LSN both identifies changes that were committed within the same transaction, and orders those transactions. __$seqval 列は、同じトランザクション内で発生したさらに多くの変更を順序付けるために使用できる列です。The column __$seqval can be used to order more changes that occur in the same transaction. __$operation 列は、変更に関連付けられている操作を記録します(1 = 削除、2 = 挿入、3 = 更新 (前イメージ)、4 = 更新 (後イメージ))。The column __$operation records the operation that is associated with the change: 1 = delete, 2 = insert, 3 = update (before image), and 4 = update (after image). __$update_mask 列は、キャプチャ対象列ごとに 1 つのビットを定義する可変ビット マスクです。The column __$update_mask is a variable bit mask with one defined bit for each captured column. 挿入と削除のエントリでは常にすべてのビットが設定されます。For insert and delete entries, the update mask will always have all bits set. 更新の行では、変更された列に対応するビットのみが設定されます。Update rows, however, will only have those bits set that correspond to changed columns.

データベースの変更データ キャプチャの有効期間Change Data Capture Validity Interval for a Database

データベースの変更データ キャプチャの有効期間とは、キャプチャ インスタンスが変更データを利用できる期間です。The change data capture validity interval for a database is the time during which change data is available for capture instances. この有効期間は、データベース テーブルに対して最初のキャプチャ インスタンスが作成されたときに始まり、現在まで続きます。The validity interval begins when the first capture instance is created for a database table, and continues to the present time.

変更テーブルに格納されるデータは、定期的かつ体系的にクリーンアップしないと、増大して管理しきれなくなります。Data that is deposited in change tables will grow unmanageably if you do not periodically and systematically prune the data. このため、変更データ キャプチャのクリーンアップ プロセスにより、保有期間に基づくクリーンアップ ポリシーが適用されます。The change data capture cleanup process is responsible for enforcing the retention-based cleanup policy. このプロセスでは、まず、時間制限を満たすように有効期間の下端が移動されます。First, it moves the low endpoint of the validity interval to satisfy the time restriction. 次に、有効期限が切れた変更テーブル エントリが削除されます。Then, it removes expired change table entries. 既定では、3 日分のデータが保持されます。By default, three days of data is retained.

上端では、キャプチャ プロセスによって変更データの新しいバッチがコミットされるたびに、変更テーブルのエントリを持つ各トランザクションに対応する新しいエントリが cdc.lsn_time_mapping に追加されます。At the high end, as the capture process commits each new batch of change data, new entries are added to cdc.lsn_time_mapping for each transaction that has change table entries. このマッピング テーブルでは、コミット ログ シーケンス番号 (LSN) とトランザクションのコミット時間の両方 (columns start_lsn と tran_end_time) が保持されます。Within the mapping table, both a commit Log Sequence Number (LSN) and a transaction commit time (columns start_lsn and tran_end_time, respectively) are retained. cdc.lsn_time_mapping 内で最も大きい LSN 値は、データベースの有効期間の上限を表します。The maximum LSN value that is found in cdc.lsn_time_mapping represents the high water mark of the database validity window. それに対応するコミット時間は、保有期間に基づくクリーンアップの新しい下限を計算するための基礎として使用されます。Its corresponding commit time is used as the base from which retention based cleanup computes a new low water mark.

キャプチャ プロセスではトランザクション ログから変更情報を抽出するため、変更がソース テーブルにコミットされてから、関連付けられている変更テーブルにその変更が反映されるまでの間に、構造的な待機時間が生じます。Because the capture process extracts change data from the transaction log, there is a built in latency between the time that a change is committed to a source table and the time that the change appears within its associated change table. この待機時間は一般に小さいとはいえ、関連するログ エントリの処理がキャプチャ プロセスによって完了するまでは変更データを利用できないということを覚えておく必要があります。While this latency is typically small, it is nevertheless important to remember that change data is not available until the capture process has processed the related log entries.

キャプチャ インスタンスの変更データ キャプチャの有効期間Change Data Capture Validity Interval for a Capture Instance

データベースの有効期間と個々のキャプチャ インスタンスの有効期間は一致するのが一般的ですが、一致しない場合もあります。Although it is common for the database validity interval and the validity interval of individual capture instance to coincide, this is not always true. キャプチャ インスタンスの有効期間は、キャプチャ プロセスがそのキャプチャ インスタンスを認識して、関連する変更のログをその変更テーブルに記録し始めたときに始まります。The validity interval of the capture instance starts when the capture process recognizes the capture instance and starts to log associated changes to its change table. その結果、キャプチャ インスタンスが別々の時間に作成された場合は、最初は各キャプチャ インスタンスがそれぞれ異なる下端を持つことになります。As a result, if capture instances are created at different times, each will initially have a different low endpoint. 定義されている各キャプチャ インスタンスの現在の下端は、 sys.sp_cdc_help_change_data_capture によって返される結果セットの start_lsn 列で確認できます。The start_lsn column of the result set that is returned by sys.sp_cdc_help_change_data_capture shows the current low endpoint for each defined capture instance. クリーンアップ プロセスによって変更テーブルのエントリがクリーンアップされると、すべてのキャプチャ インスタンスの start_lsn 値が、使用可能な変更データの新しい下限を反映して調整されます。When the cleanup process cleans up change table entries, it adjusts the start_lsn values for all capture instances to reflect the new low water mark for available change data. 調整されるのは、その時点で start_lsn 値が新しい下限より小さいキャプチャ インスタンスだけです。Only those capture instances that have start_lsn values that are currently less than the new low water mark are adjusted. 通常は、新しいキャプチャ インスタンスが作成されなければ、時間が経つにつれて、すべてのインスタンスの有効期間がデータベースの有効期間と一致するようになります。Over time, if no new capture instances are created, the validity intervals for all individual instances will tend to coincide with the database validity interval.

有効期間は変更データのコンシューマーにとって重要です。これは、要求の抽出範囲が、キャプチャ インスタンスの現在の変更データ キャプチャの有効期間によって完全にカバーされている必要があるからです。The validity interval is important to consumers of change data because the extraction interval for a request must be fully covered by the current change data capture validity interval for the capture instance. 抽出範囲の下端が有効期間の下端より左にある場合は、積極的なクリーンアップによって変更データが失われる可能性があります。If the low endpoint of the extraction interval is to the left of the low endpoint of the validity interval, there could be missing change data due to aggressive cleanup. 抽出範囲の上端が有効期間の上端より右にある場合も、その抽出範囲によって表される期間の処理がまだ完了していないために、変更データが失われる可能性があります。If the high endpoint of the extraction interval is to the right of the high endpoint of the validity interval, the capture process has not yet processed through the time period that is represented by the extraction interval, and change data could also be missing.

関数 sys.fn_cdc_get_min_lsn はキャプチャ インスタンスの LSN の現在の最小値の取得に使用し、 sys.fn_cdc_get_max_lsn は LSN の現在の最大値の取得に使用します。The function sys.fn_cdc_get_min_lsn is used to retrieve the current minimum LSN for a capture instance, while sys.fn_cdc_get_max_lsn is used to retrieve the current maximum LSN value. 変更データのクエリを実行する際には、指定する LSN の範囲がこの 2 つの LSN 値の間にないと、変更データ キャプチャのクエリ関数が失敗します。When querying for change data, if the specified LSN range does not lie within these two LSN values, the change data capture query functions will fail.

ソース テーブルに対する変更の処理Handling Changes to Source Tables

追跡対象となるソース テーブルの列の変更への対応は、下流のコンシューマーにとって困難な課題になります。To accommodate column changes in the source tables that are being tracked is a difficult issue for downstream consumers. ソース テーブルで変更データ キャプチャを有効にしても、そうした DDL の変更の発生を防ぐことはできませんが、変更データ キャプチャを使用すると、基になるソース テーブルの列構造が変更されていた場合でも、API を通じて返される、配信される結果セットは変更されないようにすることで、コンシューマーへの影響を緩和することができます。Although enabling change data capture on a source table does not prevent such DDL changes from occurring, change data capture helps to mitigate the effect on consumers by allowing the delivered result sets that are returned through the API to remain unchanged even as the column structure of the underlying source table changes. この固定された列構造は、定義済みのクエリ関数がアクセスする基になる変更テーブルにも反映されます。This fixed column structure is also reflected in the underlying change table that the defined query functions access.

変更テーブルへの書き込みを行うキャプチャ プロセスでは、列構造が固定された変更テーブルに対応するために、ソース テーブルで変更データ キャプチャが有効にされたときにキャプチャ対象として指定されていない新しい列は無視されます。To accommodate a fixed column structure change table, the capture process responsible for populating the change table will ignore any new columns that are not identified for capture when the source table was enabled for change data capture. 追跡されている列が削除された場合には、その後の変更エントリでその列に NULL 値が割り当てられます。If a tracked column is dropped, null values will be supplied for the column in the subsequent change entries. 一方、既存の列のデータ型が変更された場合は、追跡されている列のデータが失われないようにするために、その変更が変更テーブルに反映されます。However, if an existing column undergoes a change in its data type, the change is propagated to the change table to ensure that the capture mechanism does not introduce data loss to tracked columns. また、追跡されているテーブルの列構造の変更が検出されると、その変更が cdc.ddl_history テーブルに書き込まれます。The capture process also posts any detected changes to the column structure of tracked tables to the cdc.ddl_history table. 下流のアプリケーションで調整を加える必要がある場合に通知されるようにするには、 sys.sp_cdc_get_ddl_historyストアド プロシージャを使用します。Consumers wishing to be alerted of adjustments that might have to be made in downstream applications, use the stored procedure sys.sp_cdc_get_ddl_history.

通常は、関連付けられているソース テーブルに DDL の変更が適用されても、現在のキャプチャ インスタンスの構造はそのまま保持されます。Typically, the current capture instance will continue to retain its shape when DDL changes are applied to its associated source table. ただし、そのテーブルの 2 つ目のキャプチャ インスタンスを作成して、そのインスタンスに新しい列構造が反映されるようにすることもできます。However, it is possible to create a second capture instance for the table that reflects the new column structure. これにより、同じソース テーブルに対する変更が、それぞれ異なる列構造を持つ 2 つの個別の変更テーブルに記録されるようになります。This allows the capture process to make changes to the same source table into two distinct change tables having two different column structures. その結果、一方の変更テーブルで現在実行中のプログラムに引き続きデータを提供しながら、もう一方の変更テーブルを開発環境で使用して新しい列データの組み込みに取り組むことができます。Thus, while one change table can continue to feed current operational programs, the second one can drive a development environment that is trying to incorporate the new column data. このようにキャプチャ メカニズムで両方の変更テーブルに並行してデータを書き込むことができれば、一方の変更テーブルからもう一方の変更テーブルに、変更データを失うことなく移行できるようになります。Allowing the capture mechanism to populate both change tables in tandem means that a transition from one to the other can be accomplished without loss of change data. この移行は、2 つの変更データ キャプチャ タイムラインが重複している期間であればいつでも行うことができます。This can happen any time the two change data capture timelines overlap. 移行が完了したら、古いキャプチャ インスタンスは削除できます。When the transition is effected, the obsolete capture instance can be removed.

注意

1 つのソース テーブルに同時に関連付けることのできるキャプチャ インスタンスは最大 2 つです。The maximum number of capture instances that can be concurrently associated with a single source table is two.

キャプチャ ジョブとトランザクション レプリケーション ログ リーダーの関係Relationship Between the Capture Job and the Transactional Replication Logreader

変更データ キャプチャ プロセスのロジックは、ストアド プロシージャの sp_replcmdsに組み込まれています。これは、sqlservr.exe の一部として作成された内部サーバー関数で、トランザクション レプリケーションでトランザクション ログから変更を取得するためにも使用されます。The logic for change data capture process is embedded in the stored procedure sp_replcmds, an internal server function built as part of sqlservr.exe and also used by transactional replication to harvest changes from the transaction log. データベースで有効になっているのが変更データ キャプチャだけの場合は、sp_replcmds を呼び出すための手段として、変更データ キャプチャの SQL Server エージェント キャプチャ ジョブを作成します。When change data capture alone is enabled for a database, you create the change data capture SQL Server Agent capture job as the vehicle for invoking sp_replcmds. レプリケーションも存在する場合は、トランザクション ログ リーダーを使用するだけで、両方のコンシューマーの変更データのニーズを満たすことができます。When replication is also present, the transactional logreader alone is used to satisfy the change data needs for both of these consumers. これにより、同じデータベースでレプリケーションと変更データ キャプチャの両方が有効になっている場合にログの競合を大幅に削減できます。This strategy significantly reduces log contention when both replication and change data capture are enabled for the same database.

変更データをキャプチャするためのこの 2 つの操作モードの切り替えは、変更データ キャプチャが有効になっているデータベースのレプリケーションの状態が変更されるたびに自動的に行われます。The switch between these two operational modes for capturing change data occurs automatically whenever there is a change in the replication status of a change data capture enabled database.

重要

キャプチャ ロジックのインスタンスはどちらも、 SQL ServerSQL Server エージェントが実行されていないとプロセスを実行できません。Both instances of the capture logic require SQL ServerSQL Server Agent to be running for the process to execute.

キャプチャ プロセスの主なタスクは、ログをスキャンして、列データとトランザクション関連の情報を変更データ キャプチャの変更テーブルに書き込むことです。The principal task of the capture process is to scan the log and write column data and transaction related information to the change data capture change tables. キャプチャ プロセスでは、データを書き込むすべての変更データ キャプチャ変更テーブルでトランザクション的に一貫した境界を確保するために、各スキャン サイクルで独自のトランザクションを開いてコミットします。To ensure a transactionally consistent boundary across all the change data capture change tables that it populates, the capture process opens and commits its own transaction on each scan cycle. 新たに変更データ キャプチャが有効にされたテーブルがあるとそれが検出されて、ログの変更エントリをアクティブに監視するテーブルのセットにそのテーブルが自動的に追加されます。It detects when tables are newly enabled for change data capture, and automatically includes them in the set of tables that are actively monitored for change entries in the log. 同様に、変更データ キャプチャが無効にされた場合にもそれが検出されて、変更データをアクティブに監視するテーブルのセットからそのソース テーブルが削除されます。Similarly, disabling change data capture will also be detected, causing the source table to be removed from the set of tables actively monitored for change data. ログのセクションの処理が完了すると、サーバー ログ切り捨てロジックに情報が送られて、切り捨ての対象となるログ エントリが識別されます。When processing for a section of the log is finished, the capture process signals the server log truncation logic, which uses this information to identify log entries eligible for truncation.

注意

データベースの変更データ キャプチャが有効になっている場合は、復旧モードが単純復旧に設定されていても、キャプチャ対象としてマークされた変更がすべてキャプチャ プロセスで収集されるまで、ログの切り捨て位置が進められることはありません。When a database is enabled for change data capture, even if the recovery mode is set to simple recovery the log truncation point will not advance until all the changes that are marked for capture have been gathered by the capture process. キャプチャ プロセスが実行されておらず、収集対象の変更がある場合は、CHECKPOINT を実行してもログが切り捨てられることはありません。If the capture process is not running and there are changes to be gathered, executing CHECKPOINT will not truncate the log.

キャプチャ プロセスは、追跡対象のテーブルに対する DDL の変更の履歴を保持するためにも使用されます。The capture process is also used to maintain history on the DDL changes to tracked tables. 変更データ キャプチャが有効になっているデータベースまたはテーブルが削除されたり、変更データ キャプチャが有効になっているテーブルの列が追加、変更、または削除されたりするたびに、変更データ キャプチャに関連付けられている DDL ステートメントのエントリがデータベース トランザクション ログに作成されます。The DDL statements that are associated with change data capture make entries to the database transaction log whenever a change data capture-enabled database or table is dropped or columns of a change data capture-enabled table are added, modified, or dropped. これらのログ エントリがキャプチャ プロセスによって処理されると、関連する DDL イベントが cdc.ddl_history テーブルに書き込まれます。These log entries are processed by the capture process, which then posts the associated DDL events to the cdc.ddl_history table. 追跡対象のテーブルに影響を与えた DDL イベントに関する情報を取得するには、 sys.sp_cdc_get_ddl_historyストアド プロシージャを使用します。You can obtain information about DDL events that affect tracked tables by using the stored procedure sys.sp_cdc_get_ddl_history.

変更データ キャプチャのエージェント ジョブChange Data Capture Agent Jobs

変更データ キャプチャが有効になっているデータベースには、通常、2 つの SQL ServerSQL Server エージェント ジョブが関連付けられています。1 つはデータベース変更テーブルへの書き込みに使用されるジョブ、もう 1 つは変更テーブルのクリーンアップを行うジョブです。Two SQL ServerSQL Server Agent jobs are typically associated with a change data capture enabled database: one that is used to populate the database change tables, and one that is responsible for change table cleanup. どちらのジョブも、 Transact-SQLTransact-SQL コマンドを実行する 1 つの手順で構成されています。Both jobs consist of a single step that runs a Transact-SQLTransact-SQL command. 呼び出される Transact-SQLTransact-SQL コマンドは、ジョブのロジックを実装する変更データ キャプチャの定義済みストアド プロシージャです。The Transact-SQLTransact-SQL command that is invoked is a change data capture defined stored procedure that implements the logic of the job. これらのジョブは、データベースの最初のテーブルの変更データ キャプチャを有効にしたときに作成されます。The jobs are created when the first table of the database is enabled for change data capture. クリーンアップ ジョブは常に作成されます。The Cleanup Job is always created. キャプチャ ジョブは、データベースに定義済みのトランザクション パブリケーションがない場合にのみ作成されます。The capture job will only be created if there are no defined transactional publications for the database. データベースで変更データ キャプチャとトランザクション レプリケーションの両方が有効になっている場合に、データベースに定義済みのパブリケーションがなくなったためにトランザクション ログ リーダー ジョブが削除されたときにも作成されます。The capture job is also created when both change data capture and transactional replication are enabled for a database, and the transactional logreader job is removed because the database no longer has defined publications.

キャプチャ ジョブとクリーンアップ ジョブはどちらも既定のパラメーターを使用して作成されます。Both the capture and cleanup jobs are created by using default parameters. キャプチャ ジョブはすぐに開始され、The capture job is started immediately. 継続的に実行されます。各スキャン サイクルで最大 1000 のトランザクションが処理されます。サイクル間の待ち時間は 5 秒です。It runs continuously, processing a maximum of 1000 transactions per scan cycle with a wait of 5 seconds between cycles. クリーンアップ ジョブは毎日午前 2 時に実行されます。The cleanup job runs daily at 2 A.M. 変更テーブルのエントリは 4320 分 (3 日間) 保持されます。1 つの DELETE ステートメントで最大 5000 のエントリを削除できます。It retains change table entries for 4320 minutes or 3 days, removing a maximum of 5000 entries with a single delete statement.

変更データ キャプチャのエージェント ジョブは、データベースで変更データ キャプチャが無効にされると削除されます。The change data capture agent jobs are removed when change data capture is disabled for a database. また、変更データ キャプチャとトランザクション レプリケーションの両方が有効になっている場合に、データベースに最初のパブリケーションが追加されたときに削除されることもあります。The capture job can also be removed when the first publication is added to a database, and both change data capture and transactional replication are enabled.

内部では、 sys.sp_cdc_add_job ストアド プロシージャと sys.sp_cdc_drop_jobストアド プロシージャをそれぞれ使用して、変更データ キャプチャのエージェント ジョブが作成および削除されます。Internally, change data capture agent jobs are created and dropped by using the stored procedures sys.sp_cdc_add_job and sys.sp_cdc_drop_job, respectively. これらのストアド プロシージャは、管理者がこれらのジョブの作成および削除を制御できるように公開されています。These stored procedures are also exposed so that administrators can control the creation and removal of these jobs.

変更データ キャプチャのエージェント ジョブについて、既定の構成を管理者が明示的に制御することはできませんが、An administrator has no explicit control over the default configuration of the change data capture agent jobs. 既定の構成パラメーターを変更できるように sys.sp_cdc_change_job ストアド プロシージャが用意されています。The stored procedure sys.sp_cdc_change_job is provided to allow the default configuration parameters to be modified. さらに、 sys.sp_cdc_help_jobs ストアド プロシージャを使用すると、現在の構成パラメーターを表示できます。In addition, the stored procedure sys.sp_cdc_help_jobs allows current configuration parameters to be viewed. キャプチャ ジョブとクリーンアップ ジョブの構成パラメーターは、どちらも起動時に msdb.dbo.cdc_jobs テーブルから抽出されます。Both the capture job and the cleanup job extract configuration parameters from the table msdb.dbo.cdc_jobs on startup. sys.sp_cdc_change_job を使用してこれらの値に変更を加えた場合、その変更を有効にするには、ジョブをいったん停止してから再開する必要があります。Any changes made to these values by using sys.sp_cdc_change_job will not take effect until the job is stopped and restarted.

変更データ キャプチャのエージェント ジョブを開始および停止できるように、さらに 2 つのストアド プロシージャ ( sys.sp_cdc_start_jobsys.sp_cdc_stop_job) が用意されています。Two additional stored procedures are provided to allow the change data capture agent jobs to be started and stopped: sys.sp_cdc_start_job and sys.sp_cdc_stop_job.

注意

キャプチャ ジョブを開始したり停止したりしても、変更データが失われることはありません。Starting and stopping the capture job does not result in a loss of change data. 変更テーブルに格納される変更エントリについて、アクティブにログがスキャンされなくなるだけです。It only prevents the capture process from actively scanning the log for change entries to deposit in the change tables. 要求のピーク時にキャプチャ ジョブを停止して、ピーク時を過ぎたら再開することにより、ログ スキャンの負荷をピーク時に合理的に取り除くことができます。A reasonable strategy to prevent log scanning from adding load during periods of peak demand is to stop the capture job and restart it when demand is reduced.

この 2 つの SQL ServerSQL Server エージェント ジョブはどちらも、変更データ キャプチャ環境の基本的なニーズに対応できるように十分な柔軟性と構成可能性を備えていますが、Both SQL ServerSQL Server Agent jobs were designed to be flexible enough and sufficiently configurable to meet the basic needs of change data capture environments. コア機能を提供する基になるストアド プロシージャが公開されているため、さらなるカスタマイズも可能です。In both cases, however, the underlying stored procedures that provide the core functionality have been exposed so that further customization is possible.

NETWORK SERVICE アカウントでデータベース エンジン サービスまたは SQL Server エージェント サービスを実行中の場合、変更データ キャプチャは正しく機能できません。Change data capture cannot function properly when the Database Engine service or the SQL Server Agent service is running under the NETWORK SERVICE account. この結果、エラー 22832 が発生します。This can result in error 22832.

データベースとテーブルの照合順序が違う場合の対応Working with database and table collation differences

データベースの照合順序と、変更データ キャプチャ用に構成されたテーブルの列の照合順序が異なる状況について認識しておくことが重要です。It is important to be aware of a situation where you have different collations between the database and the columns of a table configured for change data capture. CDC は、中間記憶域を使用して、サイド テーブルを設定します。CDC uses interim storage to populate side tables. テーブルにデータベースの照合順序とは異なる照合順序を持つ CHAR または VARCHAR 型の列があり、これらの列に非 ASCII 文字 (2 バイト DBCS 文字など) が格納される場合、CDC は変更されたデータとベース テーブル内のデータの整合性を維持できない可能性があります。If a table has CHAR or VARCHAR columns with collations that are different from the database collation and if those columns store non-ASCII characters (such as double byte DBCS characters), CDC might not be able to persist the changed data consistent with the data in the base tables. これは、中間記憶域の変数には照合順序を関連付けることができないためです。This is due to the fact that the interim storage variables cannot have collations associated with them.

変更キャプチャ データとベース テーブルの整合性を保つには、次のいずれかの方法を検討してください。Please consider one of the following approaches to ensure change captured data is consistent with base tables:

  • 非 ASCII データを格納する列には NCHAR または NVARCHAR データ型を使用します。Use NCHAR or NVARCHAR data type for columns containing non-ASCII data.

  • または、列とデータベースに同じ照合順序を使用します。Or, Use the same collation for columns and for the database.

たとえば、SQL_Latin1_General_CP1_CI_AS の照合順序を使用するデータベースがある場合について、次のようなテーブルを考えます。For example, if you have one database that uses a collation of SQL_Latin1_General_CP1_CI_AS, consider the following table:

CREATE TABLE T1( 
     C1 INT PRIMARY KEY, 
     C2 VARCHAR(10) collate Chinese_PRC_CI_AI)

列 C2 の照合順序が異なるので (Chinese_PRC_CI_AI)、この列に対するバイナリ データの CDC は失敗する可能性があります。CDC might fail to capture the binary data for column C2, because its collation is different (Chinese_PRC_CI_AI). この問題を回避するには、NVARCHAR を使用します。Use NVARCHAR to avoid this problem:

CREATE TABLE T1( 
     C1 INT PRIMARY KEY, 
     C2 NVARCHAR(10) collate Chinese_PRC_CI_AI --Unicode data type, CDC works well with this data type)

参照See Also

データ変更の追跡 (SQL Server) Track Data Changes (SQL Server)
変更データ キャプチャの有効化と無効化 (SQL Server) Enable and Disable Change Data Capture (SQL Server)
変更データの処理 (SQL Server) Work with Change Data (SQL Server)
変更データ キャプチャの管理と監視 (SQL Server)Administer and Monitor Change Data Capture (SQL Server)