変更データ キャプチャの管理と監視 (SQL Server)Administer and Monitor Change Data Capture (SQL Server)

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

このトピックでは、変更データ キャプチャを管理および監視する方法について説明します。This topic describes how to administer and monitor change data capture.

キャプチャ ジョブCapture Job

キャプチャ ジョブは、パラメーターなしのストアド プロシージャ sp_MScdc_capture_job を実行することによって開始されます。The capture job is initiated by running the parameterless stored procedure sp_MScdc_capture_job. このストアド プロシージャは、msdb.dbo.cdc_jobs からキャプチャ ジョブの maxtransmaxscanscontinuous、および pollinginterval の構成値を抽出することによって開始されます。This stored procedure starts by extracting the configured values for maxtrans, maxscans, continuous, and pollinginterval for the capture job from msdb.dbo.cdc_jobs. これらの構成値は、パラメーターとしてストアド プロシージャ sp_cdc_scan に渡されます。These configured values are then passed as parameters to the stored procedure sp_cdc_scan. これは sp_replcmds を呼び出してログ スキャンを実行する場合に使用されます。This is used to invoke sp_replcmds to perform the log scan.

キャプチャ ジョブのパラメーターCapture Job Parameters

キャプチャ ジョブの動作を理解するには、sp_cdc_scan における構成可能パラメーターの使用方法について理解する必要があります。To understand capture job behavior, you must understand how the configurable parameters are used by sp_cdc_scan.

maxtrans パラメーターmaxtrans Parameter

maxtrans パラメーターは、ログの単一のスキャン サイクルで処理できるトランザクションの最大数を指定します。The maxtrans parameter specifies the maximum number of transactions that can be processed in a single scan cycle of the log. スキャン時に、処理するトランザクションの数がこの制限値に達すると、現在のスキャンにはそれ以上のトランザクションは含まれません。If, during the scan, the number of transactions to be processed reaches this limit, no additional transactions are included in the current scan. スキャン サイクルの完了後は、処理されたトランザクションの数は常に maxtrans 以下になります。After a scan cycle is complete, the number of transactions that were processed will always be less than or equal to maxtrans.

maxscans パラメーターmaxscans Parameter

maxscans パラメーターは、制御を返す前 (continuous = 0)、または waitfor を実行する前 (continuous = 1) に、ログを空にするために実行されるスキャン サイクルの最大数を指定します。The maxscans parameter specifies the maximum number of scan cycles that are attempted to drain the log before either returning (continuous = 0) or executing a waitfor (continuous = 1).

continuous パラメーターcontinuous Parameter

continuous パラメーターは sp_cdc_scan が、ログを空にするか、最大数のスキャン サイクル (ワン ショット モード) を実行した後で制御を開放するかどうかを決定します。The continuous parameter controls whether sp_cdc_scan relinquishes control in after either draining the log or executing the maximum number of scan cycles (one-shot mode). また、明示的に停止されるまで、sp_cdc_scan の実行を継続するかどうかもこのパラメーターが制御します (連続モード)。It also controls whether sp_cdc_scan continues to run until explicitly stopped (continuous mode).

ワンショット モードOne-shot Mode

ワンショット モードでは、キャプチャ ジョブは sp_cdc_scan が最大 maxtrans 回のスキャンを実行して、ログを空にして返すことを要求します。In one-shot mode, the capture job requests sp_cdc_scan to perform up to maxtrans scans to try to drain the log and return. ログに存在するトランザクションで maxtrans を超えた分は後のスキャンで処理されます。Any transactions in addition to maxtrans that are present in the log will be processed in later scans.

ワンショット モードは、処理するトランザクションのボリュームがわかっている、制御されたテストで使用され、完了時にジョブが自動的に終了するという利点があります。One-shot mode is used in controlled tests, where the volume of transactions to be processed is known, and there are advantages to the fact that the job closes automatically on when it is finished. ワンショット モードは、実稼働環境用にはお勧めできません。One-shot mode is not recommended for production use. これは、このモードではジョブ スケジュールに依存してスキャン サイクル実行の頻度が管理されるためです。This is because t relies on the job schedule to manage how frequently the scan cycle is run.

ワンショット モードでの実行時には、キャプチャ ジョブの予想スループットの上限を計算できます。これは次の計算式を使用して、1 秒あたりのトランザクション数として表します。When running in one-shot mode, you can compute an upper bound on expected throughput of the capture job, expressed in transactions per second by using the following computation:

(maxtrans * maxscans) / number of seconds between scans

ログをスキャンして変更テーブルにデータを設定するために必要な時間が 0 とあまり変わらない場合でも、ジョブの平均スループットは、単一スキャンでのトランザクションの最大許容数にスキャンの最大許容数を掛け、それをログ処理間隔の秒数で割った値を超えることはできません。Even if the time that is required to scan the log and populate the change tables were not significantly different from 0, the average throughput of the job could not exceed the value obtained by dividing the maximum allowed transactions for a single scan multiplied by the maximum allowed scans by the number of seconds separating log processing.

ワンショット モードでログ スキャンを制御する場合は、ログ処理間の秒数をジョブ スケジュールによって決める必要があります。If one-shot mode were to be used to regulate log scanning, the number of seconds between log processing would have to be governed by the job schedule. このような動作が必要な場合、ログ スキャンの再スケジュールの管理には、連続モードでのキャプチャ ジョブの実行がより適しています。When this kind of behavior is desired, running the capture job in continuous mode is a better way to manage rescheduling the log scan.

連続モードとポーリング間隔Continuous Mode and the Polling Interval

連続モードでは、キャプチャ ジョブは sp_cdc_scan が継続的に実行されることを要求します。In continuous mode, the capture job requests that sp_cdc_scan run continuously. これにより、ストアド プロシージャは、maxtrans と maxscans だけではなく、ログ処理間 (ポーリング間隔) の秒数の値を指定することにより、独自の wait ループを管理できます。This lets the stored procedure manage its own wait loop by providing not only for maxtrans and maxscans but also a value for the number of seconds between log processing (the polling interval). このモードを実行すると、キャプチャ ジョブはアクティブな状態を維持し、ログ スキャン間に WAITFOR を実行します。Running in this mode, the capture job remains active, executing a WAITFOR between log scanning.

注意

ポーリング間隔の値が 0 より大きい場合、定期的なワンショット ジョブのスループットと同じ上限が連続モードのジョブ操作にも適用されます。When the value of the polling interval is greater than 0, the same upper limit on throughput for the recurring one-shot job also applies to the job operation in continuous mode. つまり、(maxtrans * maxscans) をゼロ以外のポーリング間隔で割ると、キャプチャ ジョブで処理できる平均トランザクション数の上限が決まります。That is, (maxtrans * maxscans) divided by a nonzero polling interval will put an upper bound on the average number of transactions that can be processed by the capture job.

キャプチャ ジョブのカスタマイズCapture Job Customization

キャプチャ ジョブでは、追加のロジックを適用することにより、固定したポーリング間隔に依存せずに、新しいスキャンをすぐに開始するか、スリープ状態を経てから新しいスキャンを開始するかを決定できます。For the capture job, you can apply additional logic to determine whether a new scan begins immediately or whether a sleep is imposed before it starts a new scan instead of rely on a fixed polling interval. この決定は単に時刻に基づきます。たとえば、アクティビティのピーク時に非常に長いスリープを強制したり、その日の処理を完了し、夜間の運用に備えることが重要な 1 日の終わりにポーリング間隔を 0 にしたりします。The choice could be based merely on time of the day, perhaps enforcing very long sleeps during peak activity times, and even moving to a polling interval of 0 at close of day when it is important to complete the days processing and prepare for nightly runs. また、キャプチャ プロセスの進捗状態を監視して、午前零時までにコミットされたすべてのトランザクションのスキャンが完了して変更テーブルに格納された時刻を判断することもできます。Capture process progress could also be monitored to determine when all transactions committed by mid-night had been scanned and deposited in change tables. これにより、キャプチャ ジョブを終了して、毎日 1 回のスケジュールで再起動することが可能になります。This lets the capture job end, to be restarted by a scheduled daily restart. sp_cdc_scan を呼び出すジョブ ステップを、ユーザーが作成した sp_cdc_scan のラッパーに置き換えることにより、高度にカスタマイズされた動作を簡単に実現できます。By replacing the delivered job step calling sp_cdc_scan with a call to a user written wrapper for sp_cdc_scan, highly customized behavior can be obtained with little additional effort.

クリーンアップ ジョブCleanup Job

ここでは、変更データ キャプチャのクリーンアップ ジョブの仕組みについて説明します。This section provides information about how the change data capture cleanup job works.

クリーンアップ ジョブの構造Structure of the Cleanup Job

変更データ キャプチャでは、保有期間に基づくクリーンアップ戦略を使用して変更テーブルのサイズを管理します。Change data capture uses a retention-based cleanup strategy to manage change table size. クリーンアップ メカニズムは、最初のデータベース テーブルが有効になったときに作成された SQL ServerSQL Server エージェント Transact-SQLTransact-SQL ジョブで構成されます。The cleanup mechanism consists of a SQL ServerSQL Server Agent Transact-SQLTransact-SQL job that is created when the first database table is enabled. 単一のクリーンアップ ジョブがすべてのデータベース変更テーブルのクリーンアップを処理し、定義されたすべてのキャプチャ インスタンスに同じ保有期間値を適用します。A single cleanup job handles cleanup for all database change tables and applies the same retention value to all defined capture instances.

クリーンアップ ジョブは、パラメーターなしのストアド プロシージャ sp_MScdc_cleanup_job を実行することによって開始されます。The cleanup job is initiated by running the parameterless stored procedure sp_MScdc_cleanup_job. このストアド プロシージャは、構成された保有期間値およびしきい値をクリーンアップ ジョブのために msdb.dbo.cdc_jobs から抽出することによって開始されます。This stored procedure starts by extracting the configured retention and threshold values for the cleanup job from msdb.dbo.cdc_jobs. 保有期間値は、変更テーブルの新しい低水位マークの計算に使用します。The retention value is used to compute a new low watermark for the change tables. cdc.lsn_time_mapping テーブルの tran_end_time の最大値から指定の分数を差し引き、datetime 値として表す新しい低水位マークを取得します。The specified number of minutes is subtracted from the maximum tran_end_time value from the cdc.lsn_time_mapping table to obtain the new low water mark expressed as a datetime value. その後、CDC.lsn_time_mapping テーブルを使用して、対応する lsn 値にこの datetime 値を変換します。The CDC.lsn_time_mapping table is then used to convert this datetime value to a corresponding lsn value. テーブル内の複数のエントリが同じコミット時刻を共有する場合は、最小の lsn を持つエントリに対応する lsn が新しい低水位マークとして選択されます。If the same commit time is shared by multiple entries in the table, the lsn that corresponds to the entry that has the smallest lsn is chosen as the new low watermark. この lsn 値は sp_cdc_cleanup_change_tables に渡され、データベース変更テーブルから変更テーブル エントリが削除されます。This lsn value is passed to sp_cdc_cleanup_change_tables to remove change table entries from the database change tables.

注意

最新のトランザクションのコミット時刻を、新しい低水位マークの計算のベースとして使用する利点は、変更を特定の時刻の変更テーブルに残せることです。The advantage of using the commit time of the recent transaction as the base for computing the new low watermark is that it lets the changes remain in change tables for the specified time. これは、キャプチャ プロセスが背後で実行されている場合でも同様です。This happens even when the capture process is running behind. 実際の低水位マークの共有コミット時刻を持つ最小の lsn を選択することにより、現在の低水位マークと同じコミット時刻を持つすべてのエントリは、変更テーブル内に引き続き表示されます。All entries that have the same commit time as the current low watermark continue to be represented within the change tables by choosing the smallest lsn that has the shared commit time for the actual low watermark.

クリーンアップが実行されると、すべてのキャプチャ インスタンスの低水位マークが単一のトランザクションで最初に更新されます。When a cleanup is performed, the low watermark for all capture instances is initially updated in a single transaction. その後、使用されなくなったエントリの変更テーブルおよび cdc.lsn_time_mapping テーブルからの削除が試みられます。It then tries to remove obsolete entries from the change tables and the cdc.lsn_time_mapping table. 単一のステートメントで削除できるエントリの数は、構成可能なしきい値によって制限されます。The configurable threshold value limits how many entries are deleted in any single statement. 1 つのテーブルで削除が失敗しても、残りのテーブルで削除操作ができなくなるわけではありません。Failure to perform the delete on any individual table will not prevent the operation from being attempted on the remaining tables.

クリーンアップ ジョブのカスタマイズCleanup Job Customization

クリーンアップ ジョブの場合、カスタマイズが可能なのは、破棄する変更テーブル エントリを決定する戦略です。For the cleanup job, the possibility for customization is in the strategy used to determine which change table entries are to be discarded. 配布されたクリーンアップ ジョブでサポートされる唯一の戦略は時間ベースのものです。The only supported strategy in the delivered cleanup job is a time-based one. この状況では、新しい低水位マークは最後に処理されたトランザクションのコミット時刻から許容保有期間を引いて計算します。In that situation, the new low watermark is computed by subtracting the allowed retention period from the commit time of the last transaction processed. 基になるクリーンアップ プロシージャは、時間ではなく lsn に基づいているため、変更テーブルに保持する最小の lsn を決定する戦略はいくつもあります。Because the underlying cleanup procedures are based on lsn instead of time, any number of strategies can be used to determine the smallest lsn to keep in the change tables. 厳密には時間ベースのものはそのうちの一部のみです。Only some of these are strictly time-based. たとえばクライアントに関する知識は、変更テーブルへのアクセスを必要とするダウンストリーム プロセスを実行できない場合にフェールセーフを提供するために使用できます。Knowledge about the clients, for example, could be used to provide a failsafe if downstream processes that require access to the change tables cannot run. また、既定の戦略ではすべてのデータベースの変更テーブルのクリーンアップに同じ lsn を使用しますが、基になるクリーンアップ プロシージャを呼び出してキャプチャ インスタンス レベルでクリーンアップすることもできます。Also, although the default strategy applies the same lsn to clean up all the databases' change tables, the underlying cleanup procedure, can also be called to clean up at the capture instance level.

変更データ キャプチャ プロセスの監視Monitor the Change Data Capture Process

変更データ キャプチャ プロセスを監視すると、変更が変更テーブルに適切に書き込まれているかどうか、および書き込み時の待機時間が妥当かどうかを判断できます。Monitoring the change data capture process lets you determine if changes are being written correctly and with a reasonable latency to the change tables. また、発生する可能性のあるエラーを特定することもできます。Monitoring can also help you to identify any errors that might occur. SQL ServerSQL Server には、変更データ キャプチャの監視に役立つ 2 つの動的管理ビューが用意されています。 sys.dm_cdc_log_scan_sessionssys.dm_cdc_errorsです。includes two dynamic management views to help you monitor change data capture: sys.dm_cdc_log_scan_sessions and sys.dm_cdc_errors.

空の結果セットを含むセッションの特定Identify Sessions with Empty Result Sets

sys.dm_cdc_log_scan_sessions の各行はログ スキャン セッションを表します (ID が 0 の行を除く)。Every row in sys.dm_cdc_log_scan_sessions represents a log scan session (except the row with an ID of 0). ログ スキャン セッションは、 sp_cdc_scanの 1 回の実行に相当します。A log scan session is equivalent to one execution of sp_cdc_scan. セッション中、スキャンによって変更内容または空の結果のいずれかが返されます。During a session, the scan can either return changes or return an empty result. 結果セットが空の場合、sys.dm_cdc_log_scan_sessions の empty_scan_count 列が 1 に設定されます。If the result set is empty, the empty_scan_count column in sys.dm_cdc_log_scan_sessions is set to 1. 空の結果セットが連続する場合 (キャプチャ ジョブを連続的に実行している場合など)、既存の最後の行の empty_scan_count が増分されます。If there are consecutive empty result sets, such as if the capture job is running continuously, the empty_scan_count in the last existing row is incremented. たとえば、変更内容を返したスキャンについて、sys.dm_cdc_log_scan_sessions に既に 10 行が格納されており、5 つの空の結果が行に含まれている場合、ビューには 11 行が格納され、For example, if sys.dm_cdc_log_scan_sessions already contains 10 rows for scans that returned changes and there are five empty results in a row, the view contains 11 rows. 最後の行の empty_scan_count 列の値は 5 になります。The last row has a value of 5 in the empty_scan_count column. 空のスキャンを含むセッションを確認するには、次のクエリを実行します。To determine sessions that had an empty scan, run the following query:

SELECT * from sys.dm_cdc_log_scan_sessions where empty_scan_count <> 0

待機時間の判断Determine Latency

sys.dm_cdc_log_scan_sessions 管理ビューには、各キャプチャ セッションの待機時間を記録する列があります。The sys.dm_cdc_log_scan_sessions management view includes a column that records the latency for each capture session. 待機時間は、トランザクションがソース テーブルにコミットされてから、最後にキャプチャされたトランザクションが変更テーブルにコミットされるまでの経過時間として定義されます。Latency is defined as the elapsed time between a transaction being committed on a source table and the last captured transaction being committed on the change table. 待機時間列では、アクティブなセッションについてのみ値が設定されます。The latency column is populated only for active sessions. empty_scan_count 列の値が 0 より大きいセッションについては、待機時間列は 0 に設定されます。For sessions with a value greater than 0 in the empty_scan_count column, the latency column is set to 0. 次のクエリは、最新のセッションの平均待機時間を返します。The following query returns the average latency for the most recent sessions:

SELECT latency FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

待機時間データを使用すると、キャプチャ プロセスでのトランザクションの処理時間を確認できます。You can use latency data to determine how fast or slow the capture process is processing transactions. このデータが最も役立つのは、キャプチャ プロセスを連続的に実行している場合です。This data is most useful when the capture process is running continuously. スケジュールに従ってキャプチャ プロセスを実行している場合、トランザクションがソース テーブルにコミットされてから、スケジュールされた時間にキャプチャ プロセスが実行されるまでの間に遅延が生じるため、待機時間が長くなる可能性があります。If the capture process is running on a schedule, latency can be high because of the lag between transactions being committed on the source table and the capture process running at its scheduled time.

キャプチャ プロセスに関するもう 1 つの重要な指標はスループットです。Another important measure of capture process efficiency is throughput. これは、各セッション中に処理された 1 秒あたりの平均コマンド数です。This is the average number of commands per second that are processed during each session. セッションのスループットを確認するには、command_count 列の値を実行時間列の値で除算します。To determine the throughput of a session, divide the value in the command_count column by the value in the duration column. 次のクエリは、最新のセッションの平均スループットを返します。The following query returns the average throughput for the most recent sessions:

SELECT command_count/duration AS [Throughput] FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

データ コレクターを使用したサンプル データの収集Use Data Collector to Collect Sampling Data

SQL ServerSQL Server データ コレクターを使用すると、任意のテーブルまたは動的管理ビューからデータのスナップショットを収集して、パフォーマンス データ ウェアハウスを構築することができます。The SQL ServerSQL Server data collector lets you collect snapshots of data from any table or dynamic management view and build a performance data warehouse. データベースで変更データ キャプチャが有効になっている場合、sys.dm_cdc_log_scan_sessions ビューおよび sys.dm_cdc_errors ビューのスナップショットを一定間隔で取得すると、後の分析に役立ちます。When change data capture is enabled on a database, it is useful to take snapshots of the sys.dm_cdc_log_scan_sessions view and the sys.dm_cdc_errors view at regular intervals for later analysis. 次の手順では、sys.dm_cdc_log_scan_sessions 管理ビューからサンプル データを収集するデータ コレクターを設定します。The following procedure sets up a data collector for collecting sample data from the sys.dm_cdc_log_scan_sessions management view.

データ コレクションの構成Configuring Data Collection

  1. データ コレクターを有効にし、管理データ ウェアハウスを構成します。Enable data collector and configure a management data warehouse. 詳細については、「 データ コレクションの管理」を参照してください。For more information, see Manage Data Collection.

  2. 次のコードを実行して、変更データ キャプチャ用のカスタム データ コレクターを作成します。Execute the following code to create a custom collector for change data capture.

    USE msdb;  
    
    DECLARE @schedule_uid uniqueidentifier;  
    
    -- Collect and upload data every 5 minutes  
    SELECT @schedule_uid = (  
    SELECT schedule_uid from sysschedules_localserver_view
    WHERE name = N'CollectorSchedule_Every_5min')  
    
    DECLARE @collection_set_id int;  
    
    EXEC dbo.sp_syscollector_create_collection_set  
    @name = N' CDC Performance Data Collector',  
    @schedule_uid = @schedule_uid,
    @collection_mode = 0,
    @days_until_expiration = 30,
    @description = N'This collection set collects CDC metadata',  
    @collection_set_id = @collection_set_id output;  
    
    -- Create a collection item using statistics from
    -- the change data capture dynamic management view.  
    DECLARE @parameters xml;  
    DECLARE @collection_item_id int;  
    
    SELECT @parameters = CONVERT(xml,
        N'<TSQLQueryCollector>  
            <Query>  
              <Value>SELECT * FROM sys.dm_cdc_log_scan_sessions</Value>  
              <OutputTable>cdc_log_scan_data</OutputTable>  
            </Query>  
          </TSQLQueryCollector>');  
    
    EXEC dbo.sp_syscollector_create_collection_item  
    @collection_set_id = @collection_set_id,  
    @collector_type_uid = N'302E93D1-3424-4BE7-AA8E-84813ECF2419',  
    @name = ' CDC Performance Data Collector',  
    @frequency = 5,
    @parameters = @parameters,  
    @collection_item_id = @collection_item_id output;
    
    GO  
    
  3. SQL Server Management StudioSQL Server Management Studioで、 [管理][データ コレクション] の順に展開します。In SQL Server Management StudioSQL Server Management Studio, expand Management, and then expand Data Collection. [CDC パフォーマンス データ コレクター] を右クリックし、 [データ コレクション セットの開始] をクリックします。Right-click CDC Performance Data Collector, and then click Start Data Collection Set.

  4. 手順 1. で構成したデータ ウェアハウスで、custom_snapshots.cdc_log_scan_data テーブルを検索します。In the data warehouse you configured in step 1, locate the table custom_snapshots.cdc_log_scan_data. このテーブルには、ログ スキャン セッションのデータの履歴スナップショットが格納されています。This table provides a historical snapshot of data from log scan sessions. このデータを使用すると、待機時間やスループットなどのパフォーマンス指標を時系列で分析できます。This data can be used to analyze latency, throughput, and other performance measures over time.

フィードバックをお待ちしております。 この記事の手順やコード例の中で、古い情報や間違っている情報を見つけた場合は、ぜひお知らせください。We are listening: If you find something outdated or incorrect in this article, such as a step or a code example, please tell us. このページの下部にある [フィードバック] セクション内で [このページ] ボタンをクリックしてください。You can click the This page button in the Feedback section at the bottom of this page. SQL に関するフィードバックのすべての項目に目を通しています (通常は翌日)。We read every item of feedback about SQL, typically the next day. よろしくお願いいたします。Thanks.

スクリプト アップグレード モードScript upgrade mode

累積更新プログラムまたはサービス パックをインスタンスに適用する場合、再起動時に、インスタンスがスクリプト アップグレード モードになることがあります。When you apply cumulatives updates or service packs to an instance, at restart, the instance can enter in Script Upgrade mode. このモードでは、SQL Server が内部 CDC テーブルを分析し、アップグレードする手順を行うため、キャプチャ テーブルのインデックスなどのオブジェクトが再作成されることがあります。In this mode, SQL Server may run a step to analyze and upgrade internal CDC tables, which could result in recreating objects like indexes on capture tables. 関連するデータの量によっては、この手順にいくらかの時間がかかったり、または有効にされている CDC データベースのトランザクション ログの使用率が高くなったりする可能性があります。Depending on the amount of data involved, this step might take some time or cause high transaction log usage for enabled CDC databases.

参照See Also