SQL Server에서 MSrepl_commands가 계속 늘어나는 원인과 복제 지연 확인 방법
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
`MSrepl_commands`가 계속 늘어나는 원인은 크게 두 가지입니다. (a) 배포 에이전트가 구독자에게 명령을 적용하지 못하고 있음, (b) 클린업 작업이 동작하지 않거나 보존 기간이 너무 길다. 구분은 `MSdistribution_history`로 에이전트의 마지막 동작 시각을 확인하고, `sp_replmonitorsubscriptionpendingcmds`로 미배포 명령 수를 가져오면 판단할 수 있습니다.
この文書の適用条件
| 対象製品 | SQL Server(트랜잭션 복제 구성) |
|---|---|
| 確認バージョン | SQL Server 2008 이후(배포자의 구성에 의존하므로 세부 사항은 확인 필요) |
| 適用環境 | 온프레미스, EC2, Azure(Amazon RDS에서는 복제 구성에 제약이 있으므로 확인 필요) |
| 必要権限 | 배포 데이터베이스에 대한 참조 권한. `sp_replmonitorsubscriptionpendingcmds`는 replmonitor 역할 또는 sysadmin. 보존 기간 변경은 sysadmin |
| 実行影響 | 참조계는 변경 없음. 보존 기간 변경과 복제 재초기화는 구성에 영향을 줍니다 |
| 再起動 | 불필요 |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- 배포 데이터베이스에 대한 참조 권한
- 変更作業
- 없음(참조만)
- Production実行
- 가능
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: 配布データベースへの参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
USE [distribution];
GO
SELECT
da.id AS agent_id,
da.name AS agent_name,
da.publisher_db,
da.publication,
da.subscriber_db,
MAX(dh.time) AS last_history_time,
MAX(dh.delivered_commands) AS last_delivered_commands,
MAX(dh.delivery_latency) AS last_delivery_latency_ms
FROM dbo.MSdistribution_agents AS da
LEFT JOIN dbo.MSdistribution_history AS dh
ON da.id = dh.agent_id
GROUP BY da.id, da.name, da.publisher_db, da.publication, da.subscriber_db
ORDER BY last_history_time ASC;`last_history_time`이 현재 시각에서 크게 벗어난 에이전트는 동작하지 않고 있거나, 동작하고 있어도 이력을 기록하지 못하고 있습니다. 맨 앞(가장 오래된)에 오는 에이전트가 조사 대상입니다.
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- 배포 데이터베이스에 대한 참조 권한
- 変更作業
- 없음(참조만)
- Production実行
- 가능
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: 配布データベースへの参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
USE [distribution];
GO
SELECT TOP (50)
dh.agent_id,
da.name AS agent_name,
dh.runstatus, -- 1:開始 2:成功 3:実行中 4:アイドル 5:再試行 6:失敗
dh.start_time,
dh.time,
dh.duration,
dh.delivered_transactions,
dh.delivered_commands,
dh.delivery_rate,
dh.delivery_latency,
dh.comments
FROM dbo.MSdistribution_history AS dh
INNER JOIN dbo.MSdistribution_agents AS da
ON dh.agent_id = da.id
ORDER BY dh.time DESC;`runstatus = 6`(실패)이나 `runstatus = 5`(재시도)가 계속되면 `comments`에 오류 내용이 들어갑니다. 적용할 수 없는 명령이 있으면 거기서 배포가 멈추고 `MSrepl_commands`가 줄지 않습니다.
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- replmonitor 데이터베이스 역할 또는 sysadmin
- 変更作業
- 없음(참조만)
- Production実行
- 가능
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: replmonitor データベースロール または sysadmin
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
EXEC distribution.dbo.sp_replmonitorsubscriptionpendingcmds
@publisher = N'LEGACY-SQL01',
@publisher_db = N'SampleDB',
@publication = N'SamplePublication',
@subscriber = N'LEGACY-SQL01',
@subscriber_db = N'SampleDB',
@subscription_type = 0; -- 0: プッシュ / 1: プル미배포 명령 수(pendingcmdcount)와 처리 예상 시간이 반환됩니다. 이 값이 계속 증가한다면 원인은 구독자 쪽으로의 적용이 따라가지 못하고 있는 것((a)의 경우)입니다. 반대로 이 값이 작은데도 `MSrepl_commands`가 크다면 클린업 쪽((b)의 경우)을 의심합니다.
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- 배포 데이터베이스에 대한 참조 권한
- 変更作業
- 없음(참조만. 다만 전체 스캔을 수반)
- Production実行
- 가능하지만 대규모 배포 데이터베이스에서는 실행 시간이 길어짐
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: 配布データベースへの参照権限
-- 変更作業: なし(参照のみ。ただし全件スキャンを伴う)
-- Production 実行: 可能。ただし件数が多いと実行時間が長くなるため負荷の低い時間帯を選ぶこと
USE [distribution];
GO
-- トランザクション側(entry_time で保持範囲が分かる)
SELECT
t.publisher_database_id,
COUNT(*) AS transaction_count,
MIN(t.entry_time) AS oldest_entry_time,
MAX(t.entry_time) AS newest_entry_time
FROM dbo.MSrepl_transactions AS t
GROUP BY t.publisher_database_id;
-- コマンド側
SELECT
c.publisher_database_id,
COUNT(*) AS command_count
FROM dbo.MSrepl_commands AS c
GROUP BY c.publisher_database_id;`MSrepl_commands`는 행 수가 매우 많아질 수 있으며 `COUNT(*)`는 전체 스캔이 됩니다. 참조만 하지만 실행 시간과 I/O를 소비하므로 부하가 낮은 시간대를 선택하십시오. `oldest_entry_time`이 보존 기간(기본 72시간)보다 명백히 오래되었다면 클린업이 동작하지 않고 있는 것입니다.
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- msdb에 대한 참조 권한
- 変更作業
- 없음(참조만)
- Production実行
- 가능
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: msdb への参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT TOP (30)
j.name AS job_name,
j.enabled,
h.run_date,
h.run_time,
h.run_duration,
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 'Distribution clean up%'
ORDER BY h.run_date DESC, h.run_time DESC;기본 작업 이름은 `Distribution clean up: distribution`입니다. `enabled = 0`이나 `run_status = 0`(실패)이 계속되면 배포된 명령이 삭제되지 않아 `MSrepl_commands`가 계속 늘어납니다.
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- sysadmin 또는 배포 데이터베이스의 db_owner
- 変更作業
- 없음(참조만)
- Production実行
- 가능
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: sysadmin または配布データベースの db_owner
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
EXEC sp_helpdistributiondb @database = N'distribution';`min_distretention`(최소 보존 시간), `max_distretention`(최대 보존 시간, 기본 72시간), `history_retention`(이력 보존 시간, 기본 48시간)이 반환됩니다. 보존 기간을 길게 설정할수록 배포된 명령도 오래 남습니다.
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- sysadmin 또는 배포 데이터베이스의 db_owner
- 変更作業
- 없음(참조만. 다만 대규모 배포 DB에서는 장시간 실행)
- Production実行
- 권장하지 않음. 범위를 좁힌 후 부하가 낮은 시간대로 한정할 것
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: sysadmin または配布データベースの db_owner
-- 変更作業: なし(参照のみ。ただし高コスト)
-- Production 実行: 推奨しない。xact_seqno の範囲を必ず絞ること
EXEC distribution.dbo.sp_browsereplcmds
@xact_seqno_start = '0x00000000000000000000',
@xact_seqno_end = '0x00000000000000000000',
@publisher_database_id = 1;`sp_browsereplcmds`는 명령을 복원하여 읽을 수 있는 형태로 반환하지만, 범위를 좁히지 않고 실행하면 배포 데이터베이스 전체를 스캔합니다. 행 수가 많은 환경에서는 장시간 실행되어 배포자 전체의 성능에 영향을 주므로, `MSdistribution_history`로 특정한 `xact_seqno` 전후만으로 좁혀 사용하십시오. 위의 seqno는 형식을 보여주기 위한 예시 값입니다.
- 対象
- SQL Server 2008 이후(배포자)
- 権限
- sysadmin
- 変更作業
- 있음(배포 데이터베이스의 보존 정책이 바뀜)
- Production実行
- 실행 가능하지만 단축하면 미배포 명령이 삭제될 수 있음
-- 対象: SQL Server 2008 以降(ディストリビューター)
-- 権限: sysadmin
-- 変更作業: あり(配布データベースの保持ポリシー変更)
-- Production 実行: 可能。ただし短縮は未配布コマンド削除のリスクを伴う
-- 下の値は例示。現在の配布遅延を踏まえて決めること
EXEC sp_changedistributiondb
@database = N'distribution',
@property = N'max_distretention',
@value = 72;
EXEC sp_changedistributiondb
@database = N'distribution',
@property = N'history_retention',
@value = 48;보존 기간을 짧게 하면 클린업 대상이 늘어나지만, 구독자가 아직 받지 않은 명령이 삭제되면 해당 구독은 재초기화가 필요해집니다. 현재 배포 지연의 최댓값보다 충분히 긴 값을 유지하십시오. 수치는 예시이며 권장값이 아닙니다.
- 対象
- SQL Server 2008 이후(게시자 쪽 게시 데이터베이스에서 실행)
- 権限
- sysadmin, 또는 게시 데이터베이스의 db_owner
- 変更作業
- 있음(적체된 명령을 폐기하고 스냅샷으로부터 재동기화를 요구)
- Production実行
- 불가. 업무 정지에 상응하는 영향 평가와 실시 계획 확정이 전제
-- 対象: SQL Server 2008 以降(パブリッシャー側のパブリケーションDBで実行)
-- 権限: sysadmin または パブリケーションDBの db_owner
-- 変更作業: あり(滞留コマンドを破棄し、スナップショットからの再同期を要求)
-- Production 実行: 不可。影響評価と実施計画を確定させ、承認を得てから実施すること
USE [SampleDB];
GO
EXEC sp_reinitsubscription
@publication = N'SamplePublication',
@subscriber = N'LEGACY-SQL01',
@destination_db = N'SampleDB';재초기화를 요구하면 다음 스냅샷 적용까지 대상 구독자의 데이터는 일치하지 않습니다. 스냅샷 생성과 적용에는 데이터량에 비례한 시간과 I/O가 필요합니다. 먼저 적체의 원인(적용 오류, 클린업 정지)을 해소할 수 없는지 검토하고, 그래도 해소되지 않을 경우의 최종 수단으로 취급하십시오.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| last_history_time | 배포 에이전트가 마지막으로 이력을 기록한 시각 | 현재 시각에서 크게 벗어나 있으면 에이전트가 동작하지 않고 있음 |
| runstatus | 에이전트의 실행 상태(2:성공 5:재시도 6:실패 등) | 5나 6이 계속되면 `comments`에서 오류 내용을 확인 |
| delivery_latency | 배포 지연 | 지속적으로 증가한다면 구독자 쪽 적용이 따라가지 못하고 있음 |
| comments | 에이전트의 메시지 | 적용 시 오류 본문이 들어감. 정지의 직접적인 원인이 되는 경우가 많음 |
| pendingcmdcount | 미배포 명령 수(`sp_replmonitorsubscriptionpendingcmds`) | 크게 증가한다면 원인은 배포 쪽. 작은데도 `MSrepl_commands`가 많다면 클린업 쪽 |
| oldest_entry_time | 배포 데이터베이스에 남아 있는 가장 오래된 트랜잭션 시각 | 보존 기간을 크게 초과했다면 클린업이 동작하지 않고 있음 |
| command_count | `MSrepl_commands`의 행 수 | 시계열로 가져와 증가가 계속되는지 본다. 단발성 값으로는 판단할 수 없음 |
| run_status(클린업 작업) | 작업 실행 결과 | 0(실패)이 계속되면 `message`에서 원인을 확인 |
| max_distretention | 배포 데이터베이스의 최대 보존 시간(기본 72시간) | 너무 길게 설정되어 있지 않은지. 다만 배포 지연보다 짧게 하지 말 것 |
こういう状況で使います
- 배포 데이터베이스의 크기가 계속 늘어나 스토리지를 압박하고 있다
- 구독자 쪽 데이터가 특정 시각 이후로 업데이트되지 않는다
- 게시자 쪽 트랜잭션 로그가 해제되지 않고 `log_reuse_wait_desc`가 REPLICATION인 채로 있다
- 복제 모니터에서 배포 지연이 계속 증가하고 있다
- 스냅샷 적용이 끝나지 않거나 중간에 실패한다
考えられる原因(可能性の高い順)
01
배포 에이전트가 명령을 적용하지 못하고 있음
가장 흔한 원인입니다. 구독자 쪽의 제약 위반, 대상 행 누락, 권한 부족, 연결 끊김 등으로 적용이 실패하면 그 지점에서 배포가 멈추고 이후 명령이 쌓입니다. `MSdistribution_history`의 `comments`에 오류가 기록됩니다.
02
클린업 작업이 동작하지 않고 있음
`Distribution clean up: distribution` 작업이 비활성화되어 있거나 계속 실패하는 경우, 배포된 명령도 삭제되지 않고 남습니다. 에이전트는 정상이라도 테이블은 계속 늘어납니다.
03
보존 기간이 너무 길음
`max_distretention`을 크게 설정해 두면 배포된 명령이 장시간 보존됩니다. 안전을 위해 의도적으로 길게 설정한 경우도 있으므로, 설정의 적절성은 운영 요구사항과 함께 판단합니다.
04
구독자가 장시간 정지되어 있음
구독자 쪽 서버가 정지되어 있거나 네트워크가 끊어져 있으면 그만큼의 명령이 배포 데이터베이스에 적체됩니다. 복구 후 한꺼번에 배포되므로 그동안의 용량을 고려해야 합니다.
05
대량 업데이트가 한 번에 발생함
일괄 삭제·일괄 업데이트는 행 수만큼 명령을 생성합니다. 한 번의 처리로 수백만 행을 업데이트하면 그에 비례해 `MSrepl_commands`가 늘어납니다. 배치 분할로 평준화할 수 있습니다.
06
여러 게시에서 동일 데이터를 배포하고 있음
같은 테이블을 여러 게시에 포함시키면 게시별로 명령이 생성됩니다. 구성의 중복이 없는지 확인하십시오(구성에 의존하므로 대상 환경에서의 검증이 필요한 가설입니다).
確認手順
- 1
배포 에이전트의 마지막 동작 시각을 확인한다
参照のみ`MSdistribution_agents`와 `MSdistribution_history`를 조인하여 `last_history_time`이 오래된 에이전트를 특정합니다.
- 2
최근 실행 결과와 오류를 확인한다
参照のみ`runstatus`와 `comments`로부터 적용 시 오류로 멈춰 있지 않은지 봅니다.
- 3
미배포 명령 수를 가져온다
参照のみ`sp_replmonitorsubscriptionpendingcmds`로 원인이 배포 쪽인지 클린업 쪽인지를 구분합니다.
- 4
클린업 작업의 이력을 확인한다
参照のみ작업이 활성화되어 있는지, 최근에 성공했는지를 `msdb`에서 확인합니다.
- 5
보존 기간과 가장 오래된 데이터의 시각을 대조한다
参照のみ`sp_helpdistributiondb`의 `max_distretention`과 `MSrepl_transactions`의 `oldest_entry_time`을 비교합니다.
- 6
건수의 추이를 시계열로 가져온다
低한 번의 `COUNT(*)`로는 증가 경향을 알 수 없습니다. 시간을 두고 여러 번 가져와 계속 증가하는지 확인합니다.
対応方法
すぐに実施できる低リスクの対応
배포 에이전트의 오류를 해소한다
中`comments`에 나온 오류(제약 위반, 행 누락, 권한, 연결)를 해소하고 에이전트를 재개합니다. 적체가 해소되면 명령이 줄기 시작합니다.
클린업 작업을 활성화·재실행한다
中작업이 비활성화되어 있거나 실패 중이라면 원인을 확인한 후 활성화합니다. 적체량이 많으면 첫 삭제 처리는 시간이 걸립니다.
배포 데이터베이스의 여유 공간을 확보한다
中용량 고갈로 쓰기가 실패하는 경우, 먼저 여유를 확보한 후 원인 대응으로 진행합니다.
事前検討が必要な変更
보존 기간을 운영 실태에 맞춘다
中`max_distretention`과 `history_retention`을 실제 배포 지연의 최댓값보다 충분히 길고, 필요 이상으로 길지 않은 값으로 조정합니다. 너무 단축하면 미배포 명령이 삭제됩니다.
일괄 업데이트를 배치로 분할한다
低대량 업데이트를 분할하여 실행하면 명령 생성의 피크를 억제할 수 있습니다.
배포 지연과 적체 건수를 모니터링 항목에 추가한다
参照のみ`pendingcmdcount`와 배포 에이전트의 `last_history_time`을 정기적으로 가져와 임계값 초과 시 알립니다. 용량 고갈로 드러나기 전에 감지할 수 있습니다.
배포 데이터베이스의 배치와 크기 산정을 재검토한다
中배포 데이터베이스의 파일 배치, 초기 크기, 자동 확장 설정을 재검토하여 적체가 발생해도 즉시 고갈되지 않는 여유를 확보합니다.
専門家のレビューが必要な作業
구독 재초기화(스냅샷 재적용)
専門家レビュー必須적체된 명령을 폐기하고 초기 상태부터 다시 동기화하는 방식입니다. 재초기화 중에는 구독자 쪽 데이터가 일시적으로 일치하지 않는 기간이 생기며, 스냅샷 생성과 적용의 부하도 커집니다. 영향 평가와 실시 계획 확정이 전제입니다.
복제 구성 자체의 재검토
専門家レビュー必須게시 분할, 아티클 축소, 복제 방식 변경 등은 구성 전체에 영향을 줍니다. 설계 리뷰를 전제로 합니다.
!注意事項
- 보존 기간을 단축하면 구독자가 아직 받지 않은 명령이 삭제될 수 있습니다. 삭제된 구독은 재초기화가 필요해집니다. 현재 배포 지연의 최댓값보다 충분히 긴 값을 유지하십시오.
- `sp_browsereplcmds`는 범위를 좁히지 않고 실행하면 배포 데이터베이스 전체를 스캔합니다. 행 수가 많은 환경에서는 배포자 전체의 성능에 영향을 주므로 `xact_seqno` 범위 지정을 반드시 하십시오.
- `MSrepl_commands`에 대한 `COUNT(*)`는 전체 스캔입니다. 참조만 하지만 실행 시간과 I/O를 소비합니다.
- 구독 재초기화는 스냅샷의 재생성과 재적용을 수반하며, 그동안 구독자 쪽 데이터는 일치하지 않습니다. 업무 영향 확인과 승인이 전제입니다.
- `log_reuse_wait_desc = REPLICATION`은 트랜잭션 복제와 CDC 양쪽에서 발생합니다. 한쪽만 보고 원인을 확정하지 마십시오.
- Amazon RDS for SQL Server에서는 복제 구성에 제약이 있습니다. 배포자 배치 가능 여부와 사용 가능한 기능은 대상 환경에서 확인하십시오.
バージョン・環境による違い
これで解決しない場合に確認すること
게시자 쪽 로그 리더 에이전트
배포 데이터베이스에 명령이 들어오지 않는 경우, 원인은 배포 쪽이 아니라 로그 리더 쪽입니다. 로그 리더의 동작 현황을 확인합니다.
구독자 쪽 블로킹
적용이 느린 경우, 구독자 쪽에서 잠금 대기가 발생하고 있지 않은지 확인합니다.
배포 데이터베이스의 인덱스 단편화
적체가 장기화된 후에는 배포 데이터베이스 쪽의 인덱스 상태도 확인 대상이 됩니다.
네트워크 경로의 안정성
재시도가 반복되는 경우, 원인이 데이터베이스가 아니라 네트워크 쪽인 경우가 있습니다.
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
SQL Server 트랜잭션 복제의 배포 데이터베이스 스키마(`MSrepl_commands`, `MSrepl_transactions`, `MSdistribution_agents`, `MSdistribution_history`) 및 `sp_replmonitorsubscriptionpendingcmds`, `sp_browsereplcmds`, `sp_helpdistributiondb`, `sp_changedistributiondb`의 공개 사양에 기반한 일반적인 확인 절차입니다. 보존 기간의 구체적인 값은 환경에 의존하므로 예시에 그칩니다. Amazon RDS에서의 복제 제약은 대상 환경에서의 확인을 전제로 합니다.
よくある質問
MSrepl_commands가 계속 늘어나는 원인은 무엇입니까?
크게 두 가지입니다. 배포 에이전트가 구독자에게 명령을 적용하지 못하고 있는 경우와, 배포 클린업 작업이 동작하지 않아 배포된 명령이 삭제되지 않고 있는 경우입니다. `sp_replmonitorsubscriptionpendingcmds`의 미배포 명령 수가 크면 전자, 작은데도 테이블이 크면 후자입니다.
운영 환경에서 실행할 수 있습니까?
배포 에이전트의 상태 확인, 미배포 명령 수 가져오기, 작업 이력 참조는 모두 참조 전용이며 운영 환경에서 실행할 수 있습니다. `MSrepl_commands`의 `COUNT(*)`와 `sp_browsereplcmds`는 참조만이지만 비용이 높으므로 시간대와 범위를 좁히십시오. 보존 기간 변경과 재초기화는 영향이 큰 작업입니다.
어떤 권한이 필요합니까?
배포 데이터베이스의 테이블 참조에는 해당 데이터베이스에 대한 참조 권한이 필요합니다. `sp_replmonitorsubscriptionpendingcmds`는 replmonitor 데이터베이스 역할 또는 sysadmin, 보존 기간 변경(`sp_changedistributiondb`)은 sysadmin이 필요합니다.
보존 기간을 짧게 하면 해결됩니까?
클린업 대상은 늘어나지만, 미배포 명령까지 삭제되면 해당 구독은 재초기화가 필요해집니다. 먼저 배포가 멈춘 원인을 해소하고, 그런 다음 실제 배포 지연보다 충분히 긴 보존 기간을 설정하십시오.
결과를 어떻게 판단합니까?
단발성 건수로는 판단할 수 없습니다. `last_history_time`이 갱신되고 있는지, `pendingcmdcount`가 시계열로 증가하고 있는지, `oldest_entry_time`이 보존 기간을 초과하지 않았는지의 세 가지를 조합하여 배포 쪽 문제인지 클린업 쪽 문제인지 결정합니다.
AWS RDS에서도 사용할 수 있습니까?
Amazon RDS for SQL Server에서는 복제 구성에 제약이 있으며, 담당할 수 있는 역할도 서비스 사양에 따라 다릅니다. 배포자 배치 가능 여부를 포함하여 대상 환경에서의 확인이 필요합니다.
この文書がカバーする質問
- Snapshot Replication 지연 확인
- 배포 데이터베이스의 크기가 계속 증가하는 원인을 알고 싶다
- 구독자에게 데이터가 도달하지 않는 원인을 구분하고 싶다
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
복제의 적체는 배포 데이터베이스의 용량이 고갈되거나, 구독자 쪽 업무에서 "데이터가 오래되었다"고 알아챌 때까지 드러나지 않습니다. GIIP에서는 배포 에이전트의 마지막 동작 시각과 미배포 명령 수를 정기적으로 가져와, 증가가 일정 시간 지속된 시점에 통지하는 운영을 구성하고 있습니다. 재초기화처럼 데이터 정합성과 업무 정지에 직결되는 작업은 AI 에이전트의 자동 실행 대상에서 제외하고, 감지·원인 구분·영향 범위 정리까지를 자동화하며 실시 판단은 사람이 하는 형태로 합니다.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
SQL Server의 CDC에서 로그 스캔이 멈추지 않았는지 확인하는 방법
sys.dm_cdc_log_scan_sessions와 cdc.lsn_time_mapping, 캡처 작업의 상태로부터 CDC의 로그 스캔이 진행되고 있는지 확인하는 절차입니다.
sql-serverRDS for SQL Server에서 트랜잭션 로그 사용률을 확인하는 방법
로그 사용률을 DBCC SQLPERF(LOGSPACE)와 sys.dm_db_log_space_usage로 확인하고, 해제되지 않는 이유를 log_reuse_wait_desc로 구분하는 참조 전용 절차입니다.
sql-serverSQL Server에서 장시간 열려 있는 트랜잭션을 확인하는 SQL
sys.dm_tran_active_transactions 계열 DMV로 시작 시각·세션·마지막 실행 SQL까지 포함하여 방치된 트랜잭션을 특정하는 절차입니다.
monitoring서버와 데이터베이스를 24시간 모니터링할 때 설정할 항목
24시간 모니터링을 설계할 때의 모니터링 대상·임계값 사고방식·에스컬레이션 체계·외부 모니터링의 필요성을 계층별로 정리한 체크리스트입니다.
関連サービス
복제 지연 구분을 요청하기
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
복제 지연 구분을 요청하기