giip
SES案件登録
SQL Server専門家レビュー必須CDCログファイル障害対応監視

SQL ServerのCDCでログスキャンが止まっていないか確認する方法

公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13

結論

CDC のログスキャンが動いているかは `sys.dm_cdc_log_scan_sessions` の `last_commit_time` と `latency` で確認します。値が古いまま更新されなければ、キャプチャジョブが停止しているかエラーで止まっています。ジョブの状態は `sys.sp_cdc_help_jobs` で確認します。キャプチャが止まると未読ログが解放されず、`log_reuse_wait_desc` が REPLICATION で固定されログが肥大化します。

この文書の適用条件

対象製品SQL Server(Enterprise / Standard のうち CDC をサポートするエディション)/ Amazon RDS for SQL Server
確認バージョンSQL Server 2008 以降(CDC 利用可能エディションは版により異なるため要確認)
適用環境オンプレミス、EC2、Amazon RDS(RDS では CDC の有効化手順が異なる)
必要権限参照は対象DBの db_owner または `sys.dm_cdc_log_scan_sessions` に対する VIEW DATABASE STATE。CDC の有効化・無効化とジョブ操作は db_owner(環境により sysadmin)
実行影響確認系は参照のみ。ジョブの起動・停止、CDC の有効化・無効化は変更操作でキャプチャ対象データに影響します
再起動不要
最終検証日2026-08-13

そのまま実行できるコマンド

CDC が有効なデータベースとキャプチャ対象テーブルの確認参照のみ
対象
SQL Server 2008 以降 / Amazon RDS for SQL Server
権限
メタデータ可視性(`sys.databases` / `sys.tables`)
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sys.databases / sys.tables のメタデータ可視性
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
-- CDC が有効なデータベース
SELECT name AS database_name, is_cdc_enabled
FROM sys.databases
WHERE database_id > 4
ORDER BY name;
GO

-- キャプチャ対象テーブル
USE [SampleDB];
GO
SELECT
    s.name  AS schema_name,
    t.name  AS table_name,
    t.is_tracked_by_cdc
FROM sys.tables AS t
INNER JOIN sys.schemas AS s
        ON t.schema_id = s.schema_id
WHERE t.is_tracked_by_cdc = 1
ORDER BY s.name, t.name;

まず「そのデータベースで CDC が本当に有効か」を確認します。`log_reuse_wait_desc = REPLICATION` の原因は CDC とトランザクションレプリケーションの両方がありうるため、ここで切り分けの起点を作ります。

ログスキャンセッションの状態(この記事の中心となる確認)参照のみ
対象
SQL Server 2008 以降 / Amazon RDS for SQL Server
権限
対象DBへの接続権限と VIEW DATABASE STATE
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象DBへの接続権限と VIEW DATABASE STATE
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
USE [SampleDB];
GO
SELECT
    session_id,            -- 0 はキャプチャジョブ開始以降の集計行
    start_time,
    end_time,
    duration,
    scan_phase,
    error_count,
    start_lsn,
    end_lsn,
    tran_count,
    last_commit_lsn,
    last_commit_time,
    latency,
    empty_scan_count,
    failed_sessions_count
FROM sys.dm_cdc_log_scan_sessions
ORDER BY session_id;

`session_id = 0` の行は、キャプチャジョブが開始されてからの集計値です。`last_commit_time` が現在時刻から大きく離れている、`error_count` や `failed_sessions_count` が増えている、`latency` が大きい、といった状態がスキャン停滞の指標になります。キャプチャジョブが停止していると、このビュー自体が行を返さない(またはジョブ再起動後にリセットされる)ことがあります。

キャプチャがどの時点まで進んでいるか(LSN と時刻のマッピング)参照のみ
対象
SQL Server 2008 以降 / Amazon RDS for SQL Server
権限
対象DBへの接続権限(cdc スキーマへの参照権限)
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象DBへの接続権限(cdc スキーマへの参照権限)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
USE [SampleDB];
GO
-- キャプチャ済みの最新トランザクション時刻
SELECT TOP (10)
    start_lsn,
    tran_begin_time,
    tran_end_time,
    tran_id
FROM cdc.lsn_time_mapping
ORDER BY tran_end_time DESC;

-- 現在の最大 LSN と、それに対応する時刻
SELECT
    sys.fn_cdc_get_max_lsn()                            AS max_lsn,
    sys.fn_cdc_map_lsn_to_time(sys.fn_cdc_get_max_lsn()) AS max_lsn_time;

`tran_end_time` の最大値、および `sys.fn_cdc_map_lsn_to_time(sys.fn_cdc_get_max_lsn())` が現在時刻からどれだけ遅れているかが、キャプチャの遅延そのものです。数分〜数十分の遅れは設定次第で正常ですが、時間単位で止まっている場合はジョブ側を確認します。

キャプチャインスタンスと変更テーブルの確認参照のみ
対象
SQL Server 2008 以降 / Amazon RDS for SQL Server
権限
対象DBの db_owner または CDC メタデータへの参照権限
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象DBの db_owner または CDC メタデータへの参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
USE [SampleDB];
GO
-- キャプチャインスタンスの一覧(対象テーブル・変更テーブル名・キャプチャ列)
EXEC sys.sp_cdc_help_change_data_capture;
GO

-- 変更テーブルに実際に行が入っているか(キャプチャインスタンス名は環境に合わせる)
SELECT TOP (5)
    __$start_lsn,
    __$seqval,
    __$operation,     -- 1:削除 2:挿入 3:更新前 4:更新後
    __$update_mask
FROM cdc.dbo_SampleTable_CT
ORDER BY __$start_lsn DESC;

変更テーブル名は `cdc.<キャプチャインスタンス名>_CT` です。既定のキャプチャインスタンス名は `<スキーマ名>_<テーブル名>` になります。元テーブルを更新しているのに `_CT` に新しい行が入らない場合、キャプチャが進んでいません。

キャプチャジョブ・クリーンアップジョブの状態参照のみ
対象
SQL Server 2008 以降(SQL Agent が利用できる環境)
権限
対象DBの db_owner、および msdb への参照権限
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: SQL Server 2008 以降(SQL Agent が利用できる環境)
-- 権限: 対象DBの db_owner、および msdb への参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
USE [SampleDB];
GO
-- CDC ジョブの構成(ポーリング間隔・保持期間など)
EXEC sys.sp_cdc_help_jobs;
GO

-- CDC ジョブの登録内容
SELECT
    job_type,
    database_id,
    maxtrans,
    maxscans,
    continuous,
    pollinginterval,
    retention,
    threshold
FROM msdb.dbo.cdc_jobs;
GO

-- SQL Agent ジョブとしての稼働状況と直近の実行結果
SELECT
    j.name              AS job_name,
    j.enabled,
    h.run_date,
    h.run_time,
    h.run_status,       -- 0:失敗 1:成功 2:再試行 3:取消 4:実行中
    h.message
FROM msdb.dbo.sysjobs AS j
LEFT JOIN msdb.dbo.sysjobhistory AS h
       ON j.job_id = h.job_id
      AND h.step_id = 0        -- ジョブ全体の結果
WHERE j.name LIKE 'cdc.%'
ORDER BY h.run_date DESC, h.run_time DESC;

CDC のジョブ名は既定で `cdc.<データベース名>_capture` と `cdc.<データベース名>_cleanup` です。`enabled = 0` や `run_status = 0`(失敗)が続いていれば、そこが停止の原因です。SQL Agent が使えない環境ではジョブ方式が異なるため、対象環境の構成を確認してください。

キャプチャジョブの起動(停止していた場合)
対象
SQL Server 2008 以降 / Amazon RDS for SQL Server
権限
対象DBの db_owner(環境により sysadmin)
変更作業
あり(キャプチャジョブを開始し、未処理ログの読み取りが始まる)
Production実行
実行可能だが、滞留量によっては開始直後に I/O が増える
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象DBの db_owner(環境により sysadmin)
-- 変更作業: あり(キャプチャジョブの開始。滞留ログの読み取りが始まる)
-- Production 実行: 可能。滞留量が多い場合は I/O 増を見込むこと
USE [SampleDB];
GO
EXEC sys.sp_cdc_start_job @job_type = N'capture';

-- 停止する場合
-- EXEC sys.sp_cdc_stop_job @job_type = N'capture';

長時間停止していたキャプチャを再開すると、滞留していたログをまとめて読み込みます。ログ量が多い場合、再開直後に I/O とCPUが上昇します。業務時間帯を避けるか、`maxtrans` / `maxscans` の設定を確認してから実施してください。

CDC の無効化・再設定(専門家レビューが必要)専門家レビュー必須
対象
SQL Server 2008 以降 / Amazon RDS for SQL Server
権限
対象DBの db_owner(環境により sysadmin)
変更作業
あり(変更テーブルとキャプチャ設定を削除する。取得済みの変更履歴は失われる)
Production実行
不可。下流の連携システムへの影響評価と再同期計画が前提
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象DBの db_owner(環境により sysadmin)
-- 変更作業: あり(キャプチャインスタンスと変更テーブルを削除)
-- Production 実行: 不可。下流システムへの影響評価と再同期計画を先に確定すること
USE [SampleDB];
GO
-- テーブル単位で CDC を無効化する
EXEC sys.sp_cdc_disable_table
     @source_schema   = N'dbo',
     @source_name     = N'SampleTable',
     @capture_instance = N'dbo_SampleTable';

-- データベース全体で CDC を無効化する(すべての変更テーブルが削除される)
-- EXEC sys.sp_cdc_disable_db;

CDC の無効化は変更テーブルを削除します。まだ下流システムが読み取っていない変更履歴は復元できません。再設定後は下流側の再同期(初期ロードのやり直し)が必要になるため、影響評価と手順の確定を先に行ってください。Amazon RDS では CDC の有効化・無効化に RDS 固有のストアドプロシージャを使う場合があるため、対象環境の手順を確認してください。

結果の読み方

意味確認するポイント
session_idログスキャンセッションID(0 は集計行)0 の行でジョブ開始以降の全体傾向を見る
last_commit_time最後にキャプチャしたトランザクションのコミット時刻現在時刻との差が遅延そのもの。更新が止まっていれば停滞している
latencyスキャンの遅延継続的に増加していれば処理が追いついていない
error_countそのセッションで発生したエラー数0 以外ならエラー内容を SQL Agent ジョブ履歴で確認する
failed_sessions_count失敗したセッション数(集計行)増加していればキャプチャが繰り返し失敗している
empty_scan_count対象トランザクションが無かったスキャン回数更新が発生しているのに増え続ける場合、対象設定を確認する
tran_count処理したトランザクション数0 のまま増えない場合はスキャンが空振りしている
tran_end_time(cdc.lsn_time_mapping)キャプチャ済みトランザクションの終了時刻最大値が現在時刻からどれだけ遅れているか
run_status(sysjobhistory)ジョブ実行結果0(失敗)が続いていれば message 列で原因を確認する

こういう状況で使います

  • トランザクションログが増え続け、`log_reuse_wait_desc` が REPLICATION のまま変わらない
  • 元テーブルは更新されているのに、`cdc.<capture_instance>_CT` に新しい行が入らない
  • 下流の連携システムに届くデータが一定時刻以降で止まっている
  • CDC のキャプチャジョブが SQL Agent 上で失敗を繰り返している

考えられる原因(可能性の高い順)

  1. 01

    キャプチャジョブが停止している

    SQL Agent が停止している、ジョブが無効化されている、あるいは手動で `sys.sp_cdc_stop_job` が実行された状態です。ジョブが動いていなければログスキャンは進まず、未読ログが解放されません。

  2. 02

    キャプチャジョブがエラーで失敗し続けている

    キャプチャ対象テーブルのスキーマ変更、権限不足、変更テーブル側の容量不足などでジョブが失敗すると、`error_count` と `failed_sessions_count` が増えます。ジョブ履歴の `message` 列に原因が記録されます。

  3. 03

    データベースの復元・アタッチ後に CDC メタデータが整合していない

    CDC を有効にしたデータベースを別インスタンスへ復元・アタッチすると、CDC の状態やジョブが期待どおりに引き継がれない場合があります。復元時のオプションと、復元後のジョブ存在有無を確認してください。

  4. 04

    変更量に対してキャプチャの処理能力が不足している

    一括更新などで大量の変更が発生すると、`maxtrans` / `maxscans` / `pollinginterval` の設定次第では処理が追いつかず、遅延が累積します。この場合ジョブは動いていますが `latency` が増え続けます。

  5. 05

    トランザクションレプリケーションと CDC が同居している

    同一データベースでトランザクションレプリケーションと CDC を併用する場合、ログリーダーの動作が共通化されます。`log_reuse_wait_desc = REPLICATION` の原因がどちらかを、両方の状態から切り分ける必要があります。

  6. 06

    クリーンアップジョブが動作せず変更テーブルが肥大化している

    キャプチャは進んでいても、クリーンアップジョブが止まっていると `_CT` テーブルが保持期間を超えて増え続けます。ログ肥大化とは別の症状ですが、同時に確認すべき項目です。

確認手順

  1. 1

    CDC が有効か、対象テーブルは何かを確認する

    参照のみ

    `sys.databases.is_cdc_enabled` と `sys.tables.is_tracked_by_cdc` を参照します。

  2. 2

    ログスキャンセッションの状態を見る

    参照のみ

    `sys.dm_cdc_log_scan_sessions` の `last_commit_time`、`latency`、`error_count` を確認します。ここが最も直接的な指標です。

  3. 3

    キャプチャ済み時刻の遅れを測る

    参照のみ

    `cdc.lsn_time_mapping` の `tran_end_time` の最大値と現在時刻の差を確認します。

  4. 4

    ジョブの稼働状況と失敗内容を確認する

    参照のみ

    `sys.sp_cdc_help_jobs` と `msdb.dbo.sysjobs` / `sysjobhistory` を参照し、`enabled` と `run_status`、`message` を確認します。

  5. 5

    ログ側の症状と突き合わせる

    参照のみ

    `sys.databases.log_reuse_wait_desc` が REPLICATION であれば、CDC 停止とログ肥大化が同じ原因である可能性が高くなります。

  6. 6

    レプリケーションの有無を確認する

    参照のみ

    `is_published` / `is_subscribed` を確認し、CDC とレプリケーションのどちらが未読ログを保持しているかを切り分けます。

対応方法

すぐに実施できる低リスクの対応

  • SQL Agent とキャプチャジョブの稼働を確認して起動する

    ジョブが停止しているだけなら、`sys.sp_cdc_start_job` またはSQL Agent 側でジョブを有効化すれば再開します。滞留量が多い場合の I/O 増を見込んでください。

  • ジョブ失敗の原因メッセージを確認する

    参照のみ

    `sysjobhistory` の `message` にエラー内容が残ります。権限、スキーマ変更、容量のいずれかであることが多く、原因に応じた対処になります。

  • ログ側の空き容量を先に確保する

    ログが枯渇寸前なら、キャプチャ再開までの間に書き込みが止まらないよう空き容量を確保します。ただし根本原因の解消が先です。

事前検討が必要な変更

  • キャプチャジョブのパラメータを調整する

    `maxtrans`、`maxscans`、`pollinginterval` を `sys.sp_cdc_change_job` で調整し、変更量に対する処理能力を確保します。設定変更後は遅延の推移を再測定してください。

  • クリーンアップジョブと保持期間を見直す

    `retention` の設定と、下流システムが読み取るまでの所要時間を突き合わせます。保持期間が短すぎると未読のまま削除される可能性があります。

  • 一括更新の実行方法を見直す

    大量更新をバッチ分割することで、キャプチャの遅延ピークを抑えられます。

  • キャプチャ遅延を監視項目に加える

    参照のみ

    `last_commit_time` と現在時刻の差を定期取得し、閾値超過で通知する仕組みを用意します。ログ肥大化として顕在化する前に検知できます。

専門家のレビューが必要な作業

  • CDC の再設定(無効化と再有効化)

    専門家レビュー必須

    変更テーブルが削除され、未読の変更履歴は失われます。下流システムの再同期(初期ロードのやり直し)が必要になるため、影響評価と手順確定を前提とします。

  • スキーマ変更に伴うキャプチャインスタンスの再作成

    専門家レビュー必須

    列追加などに追随させるため、新しいキャプチャインスタンスを作成して切り替える方式です。切り替えの前後で下流の読み取り位置を管理する必要があります。

!注意事項

  • CDC の無効化(`sys.sp_cdc_disable_table` / `sys.sp_cdc_disable_db`)は変更テーブルを削除します。まだ下流システムが読み取っていない変更履歴は復元できません。
  • 長時間停止していたキャプチャを再開すると、滞留したログをまとめて読み込むため I/O とCPUが上昇します。業務時間帯を避けるか、段階的に処理量を制御してください。
  • `log_reuse_wait_desc = REPLICATION` は、CDC とトランザクションレプリケーションの両方で発生します。CDC だけを見て原因を確定しないでください。
  • キャプチャ対象テーブルのスキーマ変更は、キャプチャインスタンスの構成と食い違いを生じさせることがあります。列追加時の追随方法を運用手順として決めておいてください。
  • Amazon RDS for SQL Server では、CDC の有効化・無効化に RDS 固有の手順が用意されている場合があります。オンプレミス向けの手順をそのまま適用せず、対象環境の手順を確認してください。

バージョン・環境による違い

SQL Server 2008 以降CDC と `sys.dm_cdc_log_scan_sessions`、`cdc.lsn_time_mapping`、`sys.sp_cdc_help_jobs` が利用できます。利用可能なエディションは版によって異なるため、対象環境で確認してください。
SQL Server 2016 以降変更テーブルに `__$command_id` 列が含まれる版があります。列構成は `sys.sp_cdc_help_change_data_capture` の結果で確認してください。
Amazon RDS for SQL ServerCDC の有効化・無効化には RDS 側で用意された手順を使います。参照系のDMVとカタログビューは通常どおり使用できますが、SQL Agent ジョブの扱いを含め対象環境での確認が必要です(要確認)。

これで解決しない場合に確認すること

  • トランザクションログの `log_reuse_wait_desc`

    CDC を再開してもログが解放されない場合、別の要因(開いたトランザクション、レプリケーション)が併存していないかを確認します。

  • 変更テーブル(`_CT`)のサイズと保持期間

    クリーンアップジョブが動作しているか、`retention` の設定が下流の読み取り間隔と整合しているかを確認します。

  • 下流システムの読み取り位置

    連携側がどの LSN まで読んだかを確認し、CDC 側の保持範囲に収まっているかを見ます。

  • SQL Agent サービスの稼働状態

    ジョブが実行されない原因が CDC 側ではなく Agent サービスの停止であるケースを排除します。

この文書の根拠と限界

製品の公式ドキュメントに基づく説明

SQL Server の CDC 関連オブジェクト(`sys.dm_cdc_log_scan_sessions`、`cdc.lsn_time_mapping`、`sys.sp_cdc_help_change_data_capture`、`sys.sp_cdc_help_jobs`、`msdb.dbo.cdc_jobs`、`sys.sp_cdc_start_job` / `sys.sp_cdc_disable_table`)の公開仕様に基づく一般的な確認手順です。Amazon RDS 固有の CDC 有効化手順とエディション要件は版・サービスによって差があるため、対象環境での確認を前提としています。

よくある質問

CDCが止まるとなぜログファイルが増えるのですか?

CDC はトランザクションログを読んで変更を取り出します。キャプチャが未読のログは切り捨てできないため、ジョブが停止するとログが解放されずに蓄積します。この状態は `sys.databases` の `log_reuse_wait_desc` が REPLICATION になることで確認できます。

Productionで実行できますか?

確認用のクエリ(`sys.dm_cdc_log_scan_sessions`、`cdc.lsn_time_mapping`、`sys.sp_cdc_help_jobs`、ジョブ履歴の参照)はすべて参照専用で本番環境で実行できます。キャプチャジョブの起動は変更操作、CDC の無効化・再設定は下流システムに影響する高リスク操作です。

AWS RDSでも使用できますか?

参照系のDMVとカタログビューは Amazon RDS for SQL Server でも使用できます。ただし CDC の有効化・無効化には RDS 固有の手順が用意されている場合があり、SQL Agent ジョブの扱いも環境により異なります。対象環境の手順を必ず確認してください。

どの権限が必要ですか?

`sys.dm_cdc_log_scan_sessions` の参照には対象DBへの接続権限と VIEW DATABASE STATE、`sys.sp_cdc_help_jobs` などの CDC ストアドプロシージャの実行には対象DBの db_owner が必要です。ジョブの起動・停止や CDC の有効化・無効化は環境によって sysadmin が必要になります。

結果をどう判断しますか?

`last_commit_time` が現在時刻から大きく離れたまま更新されない、`error_count` や `failed_sessions_count` が増えている、`cdc.lsn_time_mapping` の最新 `tran_end_time` が古い、のいずれかが該当すればスキャンは進んでいません。ジョブ側の `enabled` と `run_status` を次に確認してください。

CDCを無効化すれば解決しますか?

ログ肥大化は止まりますが、変更テーブルが削除され未読の変更履歴が失われます。下流システムの再同期が必要になるため、無効化は影響評価と再同期計画を確定させたうえでの最終手段です。

この文書がカバーする質問

  • CDCのキャプチャが動いているか確認したい
  • log_reuse_wait_desc が REPLICATION から変わらない
  • cdc の _CT テーブルにデータが入らない原因を知りたい

リスク表示の意味

  • 参照のみデータと設定を変更しません。
  • 影響は限定的ですが、権限と負荷の確認が必要です。
  • 性能・ロック・コストに影響する可能性があります。
  • 障害・データ損失・復旧作業が発生する可能性があります。
  • 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

CDC の停止は、止まった瞬間には何のエラーも出ません。数時間後にログファイルが膨らみ、書き込みが失敗して初めて表面化するのが典型です。GIIP では `last_commit_time` の遅れとログの `log_reuse_wait_desc` を同時に取得し、両者が同じ方向に動いたときに原因まで結び付けて通知する運用を組んでいます。キャプチャの再開のようにデータ整合に関わる操作は自動実行の対象外とし、検知と原因の切り分けまでを自動化しています。

執筆・技術検証

GIIP プロダクション運用チーム

大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

CDC停止によるログ肥大化の調査を依頼する

同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。

CDC停止によるログ肥大化の調査を依頼する

ナレッジベース一覧へ