2025년 Oracle GoldenGate 체크포인트 래그 해결 가이드

문제 상황: 체크포인트 지연과 GETLAG의 차이

Extract가 RUNNING이어도 지연 수치가 크게 보일 수 있습니다. 이때는 프로세스 상태뿐 아니라 각 지표가 무엇을 측정하는지 먼저 구분해야 합니다.

아래는 2025년 8월 장애 기록에 남긴 조사와 재기동 사례입니다. 당시 체크포인트 지연은 3.5시간, GETLAG 결과는 1초였습니다. 이 기록을 현재 운영 환경의 상태나 재현 결과로 간주해서는 안 됩니다.

-- 모든 Extract 프로세스 상태 확인
GGSCI> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt
EXTRACT     RUNNING     01CD086E    03:30:00      00:00:00
EXTRACT     RUNNING     01CS087E    03:30:00      00:00:00
EXTRACT     RUNNING     01MD088E    03:30:00      00:00:00
EXTRACT     RUNNING     01SD085E    03:30:00      00:00:00
EXTRACT     RUNNING     01SS084E    03:30:00      00:00:00

같은 시점에 GETLAG로 확인한 마지막 레코드 처리 지연은 다음과 같았습니다:

GGSCI> SEND EXTRACT 01SS084E, GETLAG
Sending GETLAG request to EXTRACT 01SS084E ...
Last record lag 1 seconds.

조사 과정: XID와 데이터베이스 기록 대조

GGSCI> SEND EXTRACT 01SS084E, SHOWTRANS DURATION 240 MIN

------------------------------------------------------------
XID:         14.15.4795600
Items:       0
Extract:     01SS084E
Redo Thread: 1
Start Time:  2025-08-10:04:12:58
SCN:         1.4038799620 (8333766916)
Redo Seq:    74849
Redo RBA:    42582120
Status:      Running

GGSCI> SEND EXTRACT 01CD086E, SHOWTRANS DURATION 240 MIN
GGSCI> SEND EXTRACT 01CS087E, SHOWTRANS DURATION 240 MIN
GGSCI> SEND EXTRACT 01MD088E, SHOWTRANS DURATION 240 MIN
GGSCI> SEND EXTRACT 01SD085E, SHOWTRANS DURATION 240 MIN
GGSCI> SEND EXTRACT 01SS084E, SHOWTRANS DURATION 240 MIN

SQL> SELECT * FROM v$transaction 
WHERE xidusn=14 AND xidslot=15 AND xidsqn=4795600;

no rows selected

SELECT sample_time, session_id, session_serial#, sql_id, sql_opname,
       program, module, machine, event
FROM dba_hist_active_sess_history
WHERE xid = hextoraw('000E000F00492CD0')  -- XID를 RAW 형식으로 변환
AND sample_time BETWEEN 
    TO_TIMESTAMP_TZ('2025-08-10 03:45:00 +01:00','YYYY-MM-DD HH24:MI:SS TZH:TZM')
    AND TO_TIMESTAMP_TZ('2025-08-10 05:15:00 +01:00','YYYY-MM-DD HH24:MI:SS TZH:TZM')
ORDER BY sample_time;

원인 가설: 인덱스 리빌드와 시간대의 연관성

장애 기록에는 같은 날 04:00에 다음 인덱스 리빌드를 시작했다고 적혀 있습니다. SHOWTRANS와 ASH의 시각을 작업 기록과 대조할 단서로 사용했습니다:

ALTER INDEX BAPCO_MDB.CORERELATIONORIGINOIDN 
    REBUILD ONLINE NOLOGGING PARALLEL 14;
    
ALTER INDEX BAPCO_MDB.CORERELATIONORIGINTYPEN 
    REBUILD ONLINE NOLOGGING PARALLEL 14;

당시 대응: 조건을 확인한 뒤 Extract 순차 재기동

SELECT sequence#, name, first_time, next_time
FROM v$archived_log
WHERE thread# = 1 AND sequence# >= 74849
ORDER BY sequence#;

GGSCI> SEND EXTRACT 01CD086E, FORCESTOP
Sending FORCESTOP request to EXTRACT 01CD086E ...
Request processed.

-- 10-20초 대기

GGSCI> START EXTRACT 01CD086E
Sending START request to MANAGER ('GGSMGR_S3D') ...
EXTRACT 01CD086E starting

GGSCI> SEND EXTRACT 01CD086E, STATUS

EXTRACT 01CD086E (PID 12164)
Current status: In recovery[1]: Processing data
Current read position:
Redo thread #: 1
Sequence #: 74851
RBA: 271748752
Timestamp: 2025-08-10 04:13:26.000000

GGSCI> SEND EXTRACT 01CD086E, SHOWTRANS DURATION 240 MIN
No transactions found.

GGSCI> INFO EXTRACT 01CD086E
Checkpoint Lag       00:00:02 (updated 00:00:01 ago)

상태별로 구분해 사용할 모니터링 명령

다음은 당시 사용한 조회 명령입니다. SHOWTRANS의 기간 필터, GETLAG의 레코드 지연과 STATUS의 복구 상태를 구분해 해석하세요. 적용 구문과 지원 범위는 설치된 GoldenGate 버전·Extract 방식에 맞춰 확인해야 합니다:

# Transaction 상태 확인
SEND EXTRACT <group_name>, SHOWTRANS DURATION 240 MIN

# 현재 lag 확인
SEND EXTRACT <group_name>, GETLAG

# 상세 상태 확인
SEND EXTRACT <group_name>, STATUS

# 통계 보기
STATS EXTRACT <group_name> LATEST

# Lag 정보
LAG EXTRACT <group_name>

# 상세 정보
INFO EXTRACT <group_name>, DETAIL

유지보수 계획과 사전 점검

당시 정리한 재발 방지 항목입니다. 현재 설정으로 확인된 값이나 모든 환경에 적용할 권장값은 아니며, 작업 조건에 맞게 검토해야 합니다:

• 업무 부하가 낮은 시간에 유지보수: 복제 지연, 배치 일정과 복구 여유를 함께 고려해 작업 시간 선정
• 병렬도 측정과 조정: PARALLEL 4–8은 당시 검토한 예시 범위입니다. 병렬도를 낮추면 자원 경쟁은 줄어들 수 있지만 작업 시간은 늘어날 수도 있으므로 부하와 소요 시간을 측정해 결정
• 로깅 정책 확인: 유효한 FORCE LOGGING은 NOLOGGING보다 우선합니다. DDL의 LOGGING 표기와 별개로 실제 DB·테이블스페이스의 정책 및 복구·복제 요구사항 확인
• 사전 모니터링 설정: 30분은 예시 임계값입니다. 서비스 허용 지연에 맞춰 기준을 정하고 체크포인트 지연, GETLAG와 타깃 반영 상태를 함께 관찰
• 파티션 레벨 작업 고려: local/global 인덱스 구조와 지원 구문을 확인한 뒤 작업 범위·영향을 줄일 수 있는지 검토

정리: 관측 지표와 원인 판단을 분리하기

기억해야 할 사항:

• 강제 중지 전 정상 중지 가능 여부, 필요한 redo와 복구 절차 확인
• 재기동이 승인된 경우 한 프로세스씩 상태와 영향을 확인하며 진행
• 복구 위치의 진행과 타깃 반영 상태를 구분해 확인
• 지표·XID·로그 위치와 조치 결과를 기록해 다음 조사에 활용