giip
SES 안건 등록
SQL Server전문가 검토 필수レプリケーションログファイル性能障害対応

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시간)이 반환됩니다. 보존 기간을 길게 설정할수록 배포된 명령도 오래 남습니다.

특정 명령의 내용 확인(대규모 DB에서는 비용이 높음)중간
対象
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인 채로 있다
  • 복제 모니터에서 배포 지연이 계속 증가하고 있다
  • 스냅샷 적용이 끝나지 않거나 중간에 실패한다

가능한 원인(가능성이 높은 순)

  1. 01

    배포 에이전트가 명령을 적용하지 못하고 있음

    가장 흔한 원인입니다. 구독자 쪽의 제약 위반, 대상 행 누락, 권한 부족, 연결 끊김 등으로 적용이 실패하면 그 지점에서 배포가 멈추고 이후 명령이 쌓입니다. `MSdistribution_history`의 `comments`에 오류가 기록됩니다.

  2. 02

    클린업 작업이 동작하지 않고 있음

    `Distribution clean up: distribution` 작업이 비활성화되어 있거나 계속 실패하는 경우, 배포된 명령도 삭제되지 않고 남습니다. 에이전트는 정상이라도 테이블은 계속 늘어납니다.

  3. 03

    보존 기간이 너무 길음

    `max_distretention`을 크게 설정해 두면 배포된 명령이 장시간 보존됩니다. 안전을 위해 의도적으로 길게 설정한 경우도 있으므로, 설정의 적절성은 운영 요구사항과 함께 판단합니다.

  4. 04

    구독자가 장시간 정지되어 있음

    구독자 쪽 서버가 정지되어 있거나 네트워크가 끊어져 있으면 그만큼의 명령이 배포 데이터베이스에 적체됩니다. 복구 후 한꺼번에 배포되므로 그동안의 용량을 고려해야 합니다.

  5. 05

    대량 업데이트가 한 번에 발생함

    일괄 삭제·일괄 업데이트는 행 수만큼 명령을 생성합니다. 한 번의 처리로 수백만 행을 업데이트하면 그에 비례해 `MSrepl_commands`가 늘어납니다. 배치 분할로 평준화할 수 있습니다.

  6. 06

    여러 게시에서 동일 데이터를 배포하고 있음

    같은 테이블을 여러 게시에 포함시키면 게시별로 명령이 생성됩니다. 구성의 중복이 없는지 확인하십시오(구성에 의존하므로 대상 환경에서의 검증이 필요한 가설입니다).

확인 절차

  1. 1

    배포 에이전트의 마지막 동작 시각을 확인한다

    참조만

    `MSdistribution_agents`와 `MSdistribution_history`를 조인하여 `last_history_time`이 오래된 에이전트를 특정합니다.

  2. 2

    최근 실행 결과와 오류를 확인한다

    참조만

    `runstatus`와 `comments`로부터 적용 시 오류로 멈춰 있지 않은지 봅니다.

  3. 3

    미배포 명령 수를 가져온다

    참조만

    `sp_replmonitorsubscriptionpendingcmds`로 원인이 배포 쪽인지 클린업 쪽인지를 구분합니다.

  4. 4

    클린업 작업의 이력을 확인한다

    참조만

    작업이 활성화되어 있는지, 최근에 성공했는지를 `msdb`에서 확인합니다.

  5. 5

    보존 기간과 가장 오래된 데이터의 시각을 대조한다

    참조만

    `sp_helpdistributiondb`의 `max_distretention`과 `MSrepl_transactions`의 `oldest_entry_time`을 비교합니다.

  6. 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 2008 이후이 글에서 참조하는 배포 데이터베이스의 테이블(`MSrepl_commands`, `MSrepl_transactions`, `MSdistribution_agents`, `MSdistribution_history`)과 저장 프로시저를 사용할 수 있습니다.
배포자의 구성게시자와 배포자가 동일 인스턴스인지 별도 인스턴스인지에 따라 확인 대상 서버가 달라집니다. 먼저 구성을 파악한 후 실행하십시오.
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 프로덕션 운영팀

대규모 웹 서비스, SQL Server, Oracle, AWS, Azure의 설계·마이그레이션·운영에 약 30년간 종사했습니다. x12large급 AWS RDS for SQL Server 환경 12세트, 약 12만 개 테이블 규모의 Oracle 환경, 약 3TB 규모의 TiDB에서 Aurora MySQL로의 마이그레이션 경험이 있습니다. 현재도 다수의 클라우드 데이터베이스와 약 30개의 웹 서비스를 AI 에이전트와 사람 전문가가 지속적으로 모니터링·운영하고 있습니다.

관련 노하우

관련 서비스

복제 지연 구분을 요청하기

동일한 확인을 여러 환경에서 계속해야 한다면, 운영 체계 전체를 상담할 수 있습니다.

복제 지연 구분을 요청하기

← 지식 베이스 목록으로