오라클 GoldenGate 장애 대응: 조건부 재기동 + 모니터링 루프로 당일 종결

Oracle GoldenGate 장애 대응 사례: 복제 흐름의 상태와 로그를 점검하는 개념 그림
GoldenGate 장애 대응 사례: 상태 확인과 재기동 판단

증상 · 진단 가설 · 대응 절차 · 관찰 결과 · 운영 체크리스트

Oracle Middleware / GoldenGate / 운영 자동화

이 사례는 BI·배치 구간에서 STARTING 또는 UNKNOWN 표시가 오래 지속되는 현상으로 시작했습니다. STARTING은 GoldenGate의 프로세스 상태이며, UNKNOWN은 래그 값에도 표시될 수 있습니다. 어떤 출력 필드였는지 먼저 확인해야 하며 둘을 같은 프로세스 상태로 해석하면 안 됩니다. 배치 지연이 누적될 수 있어 상태 확인과 대응 기준을 정리할 필요가 있었습니다.

목표는 다운타임 최소화를 고려하면서 지연 원인을 좁히고, 현장 조건에 맞는 점검 절차를 마련하는 것이었습니다. 이 글의 당일 대응은 사례의 처리 시점을 뜻하며, 같은 절차로 모든 장애를 당일 해결할 수 있다는 의미는 아닙니다.

운영 환경과 제약

  • 대상: 운영 BI/배치 구간에서의 프로세스 상태 불안정
  • 요구사항: 다운타임 최소화, 신속한 복구 및 원인 파악
  • 제약: 고객 피크 시간대 고려, 로그/상태 점검 가시성 제한

원문은 재기동 후 초기화가 끝나기 전에 상위 모듈이 상태를 조회한 구간과 잔존 프로세스·포트 충돌이 의심되는 흔적을 설명합니다. 이는 재기동 순서와 점검 간격이 초기화 소요 시간과 맞지 않았을 가능성을 검토할 근거입니다. 원본 로그가 없는 상태에서 확정 원인으로 일반화할 수는 없습니다.

대응 전에는 프로세스와 포트의 소유자, 정상 종료 여부, 재기동 영향을 먼저 확인합니다. 임의 종료나 파일 삭제를 기본 절차로 삼지 않습니다. 루프 간격과 총 반복 횟수는 측정한 초기화 시간과 허용 지연에 맞춥니다. info all은 상태·체크포인트 래그를 확인하는 명령이며, 시작 명령과 구분해야 합니다.

핵심 요약

  • 증상: BI·배치 구간에서 프로세스 상태 표시가 오래 유지되는 간헐적 현상
  • 원인개요: 잔존 프로세스·포트 충돌과 재기동 시점의 불일치는 진단 가설이며, 로그로 확인해야 함
  • 조치: 상태 점검과 재기동 판단을 분리하고 점검 간격·횟수를 환경에 맞게 결정
  • 결과: 원문은 지표 정상화와 고객 확인 후 Same-Day Close를 보고함. 다른 환경의 복구 시간이나 재발 방지를 보장하지 않음

증상과 업무 영향

일부 프로세스가 STARTING 또는 UNKNOWN으로 표시되는 동안 상위 모듈·스케줄러가 기대한 정상 신호(Ready/Alive)를 확인하지 못한 사례입니다. UNKNOWN의 출력 필드와 이 현장 연동 신호를 구분해야 하며, 둘 다 GoldenGate 전체의 처리 정상 여부를 단독으로 입증하지는 않습니다.

  • 모니터링 지표 일시적 악화, 특정 기능 응답 지연
  • 야간 배치 연쇄 지연 위험 (누적 대기 증가)

관찰과 가설을 구분한 진단

  1. Observation: 원문은 잔존 프로세스·포트 충돌이 의심되는 흔적을 기술함
  2. Hypothesis: 재기동 순서·점검 간격과 초기화 소요 시간의 불일치 가능성
  3. Evidence: 시작·오류·상태 조회 시각과 체크포인트 진행을 대조해 가설을 검증. 대기시간 증가만으로 원인을 확정하지 않음

프로세스 상태와 포트 소유자를 확인한 뒤, 정상 종료와 재기동이 필요한지를 판단합니다. 재기동 후에는 현장의 준비 신호와 GoldenGate 상태·체크포인트 진행을 나눠 확인합니다. RUNNING 표시만으로 복제 완료나 데이터 정합성을 판단하지 않습니다.

아래 모니터링 루프는 15분 대기와 16회 반복을 둔 예시입니다. start는 프로세스를 시작하는 명령이고 info는 상태 조회 명령입니다. 예제는 매 반복마다 시작 명령을 보내며 상태별 분기나 종료·복구 판단을 구현하지 않으므로, 조건부 재기동 자동화가 완성된 코드로 사용하면 안 됩니다.

ogg_monitor.sh (예시)
#!/usr/bin/env bash
# GoldenGate 상태 점검 + 조건부 재기동 모니터링 루프 (고객 식별 정보 제거)
set -euo pipefail

OGG_HOME="/ogg/ggs19c"
SRC_CONN="app_user@SRCDB"   # 예: TNS alias
EXTRACT_GRP="EXTRACT_A"
REPLICAT_GRP="REPLICAT_A"

SLEEP_SEC=$((15*60))  # 15분 간격(=900초)
ITER=16              # 총 4시간(15분×16)
LOG="/tmp/ogg_monitor_$(date +%F_%H%M).log"

run_once() {
  "$OGG_HOME"/ggsci <<EOF | tee -a "$LOG"
dblogin userid $SRC_CONN, password ********
start extract  $EXTRACT_GRP
start replicat $REPLICAT_GRP
info all
EOF
}

main() {
  for i in $(seq 1 $ITER); do
    run_once
    sleep $SLEEP_SEC
  done
}
main
    

※ 그대로 운영에 실행하지 마세요. 이 예제에는 실제 인증 정보, 상태별 시작 조건, 실패 처리와 운영 승인 절차가 빠져 있습니다. 별표 비밀번호는 실행 가능한 인증 값이 아닙니다. 그룹·접속·자격 증명 관리와 오류 처리 방식은 해당 버전의 문서 및 내부 기준에 따라 별도로 설계해야 합니다.

SLEEP_SEC=$((15*60))는 각 실행 뒤 15분을 대기하도록 정한 값입니다. 실제 점검 시작 간격에는 명령 실행 시간도 더해집니다. 짧거나 긴 간격 중 어느 쪽이 안전한지는 초기화 시간, 허용 지연과 점검 비용을 측정해 결정해야 합니다.

ITER=16은 16회 반복을 뜻합니다. 정상적으로 모든 반복을 마치면 대기 시간의 합은 4시간이고, 전체 소요 시간에는 명령 실행 시간이 추가됩니다. 실패 시에는 더 일찍 종료될 수 있습니다. 원문의 야간 12~20회, 주간 8~16회는 사례의 설정 범위이며 일반 권장값이 아닙니다.

원문은 대응 후 상태 전이 지연이 관찰되지 않았고 상위 모듈의 Ready/Alive 신호도 안정적으로 확인됐다고 보고합니다. 다만 관찰 기간·부하·지표 원본이 제시되지 않아 영구적인 재발 방지나 단일 원인의 해소를 입증한 결과로 볼 수는 없습니다.

사례에서는 고객 확인 후 당일에 대응을 마무리했다고 기록합니다. 운영에 참고할 부분은 처리 속도의 보장보다, 상태 확인·재기동 판단·결과 검증을 구분해 기록하는 절차입니다.

배운 점

  • 잔존 프로세스와 포트 충돌은 점검 후보이며 초기화 지연의 원인으로 단정하지 않기
  • 재기동 판단은 현장 초기화 소요와 서비스 영향을 함께 고려하기
  • 로그는 첫 에러와 대기구간의 시각·대상을 기록하기

체크리스트

  • 정상 종료 여부와 프로세스·포트 소유자를 확인하고 재기동 필요성을 판단하기
  • 간격(SLEEP_SEC), 횟수(ITER)는 로그 근거와 허용 지연을 기준으로 조정하기
  • 모니터링은 상태·체크포인트 진행·래그·업무 결과를 함께 확인하기

재기동은 점검 결과에 따라 결정하고, 잔존 프로세스·포트가 보여도 소유자와 영향부터 확인합니다. 점검 간격과 반복 수는 측정한 현실의 초기화 시간과 복구 목표를 기준으로 정합니다. 실패 시 첫 오류와 대기 구간을 남기고, 종료 후에도 처리 진행과 업무 결과를 검증해야 합니다.

원문은 내부 표준 문서에 스크립트·파라미터 표·조치 전후 기록 양식을 공유했다고 설명합니다. 재현 가능한 런북을 만들려면 적용 조건, 중단 기준과 검증 항목까지 명시해야 합니다. 절차가 같아도 환경에 따라 결과는 달라질 수 있습니다.

운영 자동화나 런북 정비가 필요하시면, 현재 환경의 점검 기준과 재기동 조건부터 함께 정리하겠습니다.

프로젝트 문의하기
위로 스크롤