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(CDC를 지원하는 Enterprise / Standard 에디션) / 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 |
そのまま実行できるコマンド
- 対象
- 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`가 큰 상태가 스캔 지체의 지표입니다. 캡처 작업이 정지되어 있으면 이 뷰 자체가 행을 반환하지 않거나(또는 작업 재시작 후 리셋되는) 경우가 있습니다.
- 対象
- 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` 설정을 확인한 후 실시하십시오.
- 対象
- 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에서 반복적으로 실패한다
考えられる原因(可能性の高い順)
01
캡처 작업이 정지되어 있음
SQL Agent가 정지되어 있거나, 작업이 비활성화되어 있거나, 또는 수동으로 `sys.sp_cdc_stop_job`이 실행된 상태입니다. 작업이 동작하지 않으면 로그 스캔이 진행되지 않고 읽지 않은 로그가 해제되지 않습니다.
02
캡처 작업이 오류로 계속 실패하고 있음
캡처 대상 테이블의 스키마 변경, 권한 부족, 변경 테이블 쪽 용량 부족 등으로 작업이 실패하면 `error_count`와 `failed_sessions_count`가 증가합니다. 작업 이력의 `message` 열에 원인이 기록됩니다.
03
데이터베이스 복원·연결 후 CDC 메타데이터가 일치하지 않음
CDC를 활성화한 데이터베이스를 다른 인스턴스로 복원·연결하면 CDC의 상태나 작업이 기대한 대로 이어지지 않는 경우가 있습니다. 복원 시 옵션과 복원 후 작업 존재 여부를 확인하십시오.
04
변경량에 비해 캡처의 처리 능력이 부족함
일괄 업데이트 등으로 대량의 변경이 발생하면 `maxtrans` / `maxscans` / `pollinginterval` 설정에 따라 처리가 따라가지 못해 지연이 누적됩니다. 이 경우 작업은 동작하고 있지만 `latency`가 계속 증가합니다.
05
트랜잭션 복제와 CDC가 함께 사용되고 있음
같은 데이터베이스에서 트랜잭션 복제와 CDC를 함께 사용하는 경우, 로그 리더의 동작이 공통화됩니다. `log_reuse_wait_desc = REPLICATION`의 원인이 어느 쪽인지를 양쪽의 상태로부터 구분해야 합니다.
06
클린업 작업이 동작하지 않아 변경 테이블이 비대해지고 있음
캡처는 진행되고 있어도 클린업 작업이 멈춰 있으면 `_CT` 테이블이 보존 기간을 초과하여 계속 늘어납니다. 로그 비대화와는 다른 증상이지만 동시에 확인해야 할 항목입니다.
確認手順
- 1
CDC가 활성화되어 있는지, 대상 테이블이 무엇인지 확인한다
参照のみ`sys.databases.is_cdc_enabled`와 `sys.tables.is_tracked_by_cdc`를 참조합니다.
- 2
로그 스캔 세션의 상태를 본다
参照のみ`sys.dm_cdc_log_scan_sessions`의 `last_commit_time`, `latency`, `error_count`를 확인합니다. 여기가 가장 직접적인 지표입니다.
- 3
캡처된 시각의 지연을 측정한다
参照のみ`cdc.lsn_time_mapping`의 `tran_end_time` 최댓값과 현재 시각의 차이를 확인합니다.
- 4
작업의 동작 현황과 실패 내용을 확인한다
参照のみ`sys.sp_cdc_help_jobs`와 `msdb.dbo.sysjobs` / `sysjobhistory`를 참조하여 `enabled`, `run_status`, `message`를 확인합니다.
- 5
로그 쪽의 증상과 대조한다
参照のみ`sys.databases.log_reuse_wait_desc`가 REPLICATION이라면 CDC 정지와 로그 비대화가 같은 원인일 가능성이 높아집니다.
- 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 고유의 절차가 마련되어 있는 경우가 있습니다. 온프레미스용 절차를 그대로 적용하지 말고 대상 환경의 절차를 확인하십시오.
バージョン・環境による違い
これで解決しない場合に確認すること
트랜잭션 로그의 `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이 되는 것으로 확인할 수 있습니다.
운영 환경에서 실행할 수 있습니까?
확인용 쿼리(`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エージェントと人間の専門家が継続的に監視・運用しています。
RDS for SQL Server에서 트랜잭션 로그 사용률을 확인하는 방법
로그 사용률을 DBCC SQLPERF(LOGSPACE)와 sys.dm_db_log_space_usage로 확인하고, 해제되지 않는 이유를 log_reuse_wait_desc로 구분하는 참조 전용 절차입니다.
sql-serverSQL Server에서 MSrepl_commands가 계속 늘어나는 원인과 복제 지연 확인 방법
배포 데이터베이스의 명령 적체를, 배포 에이전트의 동작 현황과 클린업 작업·보존 기간의 양면에서 구분하는 절차입니다.
sql-serverSQL Server에서 장시간 열려 있는 트랜잭션을 확인하는 SQL
sys.dm_tran_active_transactions 계열 DMV로 시작 시각·세션·마지막 실행 SQL까지 포함하여 방치된 트랜잭션을 특정하는 절차입니다.
monitoring서버와 데이터베이스를 24시간 모니터링할 때 설정할 항목
24시간 모니터링을 설계할 때의 모니터링 대상·임계값 사고방식·에스컬레이션 체계·외부 모니터링의 필요성을 계층별로 정리한 체크리스트입니다.
関連サービス
CDC 정지로 인한 로그 비대화 조사를 요청하기
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
CDC 정지로 인한 로그 비대화 조사를 요청하기