리커버리 끝났는데
XID가 왜 안 사라지죠?
Oracle GoldenGate 체크포인트 래그 실전 삽질기 2탄
feat. 3일간의 고군분투
📖 1편 못 보신 분들을 위해
이 글은 「Oracle GoldenGate 체크포인트 래그 해결 가이드」의 후속편이에요.
1편에서 다룬 "체크포인트 래그는 높은데 GETLAG는 낮고, 모든 Extract가 같은 XID 보여주는" 그 패턴 기억하시죠? 그때 알려드린 제어된 재시작으로 해결했다고 생각했는데... 아직 끝이 아니더라고요. 😅
🤔 뭐가 문제였나요?
상황을 정리하자면요:
- 1편 방법대로 Extract들 순차 재시작 완료 ✓
- 모두 "Recovery complete: Processing data" 상태 확인 ✓
- 근데 일부 Extract(01CD086E 같은)는 여전히 SHOWTRANS에 같은 XID가... 🤷♂️
- 다음날 보니 새로운 XID(14.4.4794298)가 또 나타남!
🎭 실제 경험담
결국 38GB짜리 인덱스 2개 리빌드 때문에 전체 Extract가 따라잡는데 무려 3일이 걸렸어요. 이 경험 이후로 큰 작업할 때는 그냥 OGG 정지하고 하기로 했답니다... (현실적인 선택 🥲)
💡 알아두세요!
GETLAG(지금 얼마나 밀렸나)와 Checkpoint Lag(재시작하면 어디서부터 다시 해야 하나)는 완전히 다른 거예요! GETLAG 1초여도 체크포인트는 몇 시간 전일 수 있어요.
🔍 도대체 왜 이러는 걸까요?
현장에서 삽질하며 찾아낸 원인들이에요:
원인 1: DB는 조용한데 Extract 캐시는 아직...
원인 2: 줄줄이 이어지는 후속 작업들
원인 3: Integrated Extract의 특이한 표시
STATUS 찍어보면 가끔 이상하게 나와요:
- Redo thread #: 0
- Sequence #: 0
- RBA: 0
- 타임스탬프는 멈춰있고...
당황하지 마세요! Integrated 모드에선 종종 있는 일이에요. 진짜 확인은 INFO EXTRACT xxx, DETAIL로 해야 해요.
🛠️ 이럴 때 어떻게 하나요?
우리가 만든 3단계 확인 루틴 (5-10분마다 체크)
SEND EXTRACT 그룹명, STATUS
👉 Seq/RBA/타임스탬프가 조금이라도 움직이나요?
SEND EXTRACT 그룹명, SHOWTRANS DURATION 240 MIN
👉 똑같은 XID가 15-20분 넘게 안 바뀌나요?
STATS EXTRACT 그룹명 LATEST
👉 처리된 레코드 수가 늘어나나요?
상황별 대응법
😌 "DB가 조용해서 그래요" 신호
✓ DB 활동 거의 없음
✓ 에러 메시지 없음
✓ I/O 병목 없음
✓ 아카이브 충분함
→ 그냥 기다리세요. 건드리면 더 꼬여요!
😰 "진짜 멈춘 것 같아요" 신호
✓ 같은 XID가 15-30분 이상 완전 고정
✓ ggserr.log에 에러 없음
✓ 아카이브도 충분함
→ 해당 Extract만 조심스럽게 재시작:
GGSCI> SEND EXTRACT 그룹명, FORCESTOP
-- 꼭! 10-20초 기다리세요
GGSCI> START EXTRACT 그룹명🔬 정말 궁금하면 LogMiner로 까보세요
SHOWTRANS에 계속 나오는 그 XID, 도대체 뭘 하다가 생긴 건지 궁금하시죠? LogMiner로 직접 확인해봅시다!
-- 해당 구간 아카이브가 있는지 먼저 확인
SELECT sequence#, name, first_time, next_time
FROM v$archived_log
WHERE thread# = 1
AND sequence# BETWEEN 74849 AND 74870
ORDER BY sequence#;BEGIN
-- 첫 번째 아카이브 추가
DBMS_LOGMNR.ADD_LOGFILE(
LOGFILENAME => 'E:\ORACLE\...\첫번째아카이브.ARC',
OPTIONS => DBMS_LOGMNR.NEW
);
-- 나머지 아카이브들 추가
DBMS_LOGMNR.ADD_LOGFILE(
LOGFILENAME => 'E:\ORACLE\...\두번째아카이브.ARC',
OPTIONS => DBMS_LOGMNR.ADDFILE
);
-- LogMiner 시작!
DBMS_LOGMNR.START_LOGMNR(
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG
);
END;
/-- XID로 직접 찾기 (예: 14.15.4795600)
SELECT timestamp, scn, operation,
seg_owner, seg_name, sql_redo
FROM v$logmnr_contents
WHERE xid_usn = 14
AND xid_slot = 15
AND xid_sqn = 4795600
ORDER BY scn;결과 해석법
- COMMIT이 보이면: DB에선 이미 끝난 거예요. Extract 캐시가 밀릴 때까지 기다리거나 살짝 재시작
- COMMIT이 안 보이면: 진짜 아직 안 끝난 거예요! 어떤 작업인지 확인하고 담당자한테 연락
💼 3일간 삽질하며 배운 것들
1. 재시작은 양날의 검 ⚔️
2. 동시 리커버리는 3개가 한계
🎪 실제 경험
5개 Extract 한꺼번에 리커버리 돌렸더니 서버가 숨을 못 쉬더라고요. I/O 경쟁에 LogMiner 부하까지... 결국 3개씩 나눠서 했더니 오히려 더 빨리 끝났어요.
3. Windows 서버 특별 팁 💻
아카이브/트레일 폴더는 꼭 백신 검사에서 제외하세요! 그리고 I/O 상태 체크:
# PowerShell에서 실행
Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Transfer',
'\PhysicalDisk(_Total)\Disk Reads/sec',
'\PhysicalDisk(_Total)\Current Disk Queue Length' `
-SampleInterval 1 -MaxSamples 60Queue Length가 0 근처, sec/Transfer가 몇 ms 정도면 I/O는 문제없는 거예요.
4. Bounded Recovery의 함정
📝 인덱스 리빌드 전 체크리스트
이거 다 확인하셨나요?
🎯 결론: 이것만 기억하세요!
1️⃣ 후속 작업이 계속 진행 중이거나
2️⃣ DB가 조용해서 캐시가 안 밀려나간 거예요
대부분은 시간이 해결해줘요. 조급해하지 마세요! 🧘♂️
꼭 기억할 것들
- STATUS/SHOWTRANS/STATS 3종 세트로 판단하기
- LogMiner로 사실 확인 후 조치하기
- 아카이브는 넉넉하게 보관하기
- 무리한 병렬 재시작은 독!
- 때론 기다림이 최고의 해결책 🍵
📌 마지막 팁
1편에서 배운 기본기(패턴 파악, 순차 재시작, 예방법)는 여전히 유효해요! 거기에 이번 편의 "기다림의 미학"을 더하면 완벽! 👌
📚 자주 쓰는 명령어 모음
-- 상태 확인 3종 세트
SEND EXTRACT 그룹명, STATUS
SEND EXTRACT 그룹명, SHOWTRANS DURATION 240 MIN
STATS EXTRACT 그룹명 LATEST
-- 지연 확인
SEND EXTRACT 그룹명, GETLAG
LAG EXTRACT 그룹명
-- 조심스러운 재시작
SEND EXTRACT 그룹명, FORCESTOP
-- 꼭 기다리세요!
START EXTRACT 그룹명📥 실전 플레이북 다운로드
LogMiner 쿼리부터 체크리스트까지 다 들어있어요!
"3일간의 리커버리 대장정을 통해 깨달은 진리:
때로는 아무것도 안 하는 게 최선의 해결책이다."
- 27년차 오라클 전문가의 체념... 아니, 깨달음 😌
