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

ogg 장애대응

고객 케이스 리포트: 빠른 진단·조치로 Same-Day Close

현장 이슈 요약 · 원인 분석 · 실행 조치 · 결과 · 재발 방지 체크리스트

Oracle Middleware / GoldenGate / 운영 자동화

이 케이스는 BI/배치 구간에서 드물게 STARTING 또는 UNKNOWN 상태가 길어지는 현상으로 시작했습니다. 표면적으로는 “조금 기다리면 괜찮아진다”에 가깝지만, 배치 타이밍과 맞물리면 연쇄 지연이 생길 수 있어 운영팀의 부담이 컸습니다.

목표는 단순했습니다. 다운타임 최소화를 전제로, 원인에 가까운 지점을 빠르게 특정하고, 현장 실정에 맞는 보수적 파라미터로 안정적인 루틴을 만드는 것. 그리고 가능하면 당일 클로즈였습니다.

환경 & 배경

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

로그 타임라인을 따라가 보니, 재기동 이후 초기화가 끝나기 전에 상위 모듈이 상태를 가져가려는 구간이 있었습니다. 이때 잔존 프로세스나 포트 충돌이 의심되는 흔적이 보였고, 결국 “재기동 순서와 간격이 실제 초기화 시간과 어긋난다”는 가설에 도달했습니다.

조치 전제는 명확했습니다. 첫째, 잔존을 깨끗이 정리한다. 둘째, 루프 간격과 총 반복 횟수를 넉넉히 잡아 초기화 시간을 존중한다. 셋째, 매 루프마다 info all 등 가벼운 확인만 수행해 과도한 부하를 만들지 않는다.

TL;DR

  • 증상: 특정 BI/배치 타이밍에 프로세스 상태가 불안정해지는 간헐 이슈
  • 원인개요: 프로세스 잔존 + 재기동 타이밍 미스매치로 인한 상태 전이 지연
  • 조치: 상태 점검 → 조건부 재기동 + 모니터링 루프(간격/횟수 튜닝) 즉시 적용
  • 결과: 지표 정상화, 고객 검증 완료, Same-Day Close

증상 & 영향

간헐적으로 일부 프로세스가 STARTING 또는 UNKNOWN 상태에서 장시간 머무르며, 상위 모듈/스케줄러가 정상 신호(Ready/Alive)를 받아가지 못함.

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

진단 접근

  1. Observation: 상태 체크 시 잔존 프로세스/포트 충돌이 간헐 관측
  2. Hypothesis: 재기동 순서/간격이 실제 초기화 소요 시간과 미스매치
  3. Evidence: 로그 타임라인 비교 시 특정 구간에서 대기시간 급증

우선 프로세스 상태와 포트 충돌 가능성을 확인하고, 정리할 부분을 정리했습니다. 이후에는 재기동을 서두르지 않고, 준비 신호가 확실해질 때까지 여유를 두고 상태를 관찰했습니다.

핵심은 모니터링 루프였습니다. 15분 간격으로 상태를 점검하면서, 총 4시간 정도를 기본선으로 두었습니다. 루프 안에서는 필요 이상으로 건드리지 않고, 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은 총 모니터링 시간을 4시간으로 본다는 의미입니다. 야간 배치에 맞추면 12~20회 범위가 실무적으로 편했고, 주간 점검은 8~16회로도 충분했습니다.

조치 후에는 상태 전이 지연이 재현되지 않았고, 상위 모듈의 Ready/Alive 신호도 안정적으로 관찰되었습니다. 무엇보다 “기다림”이 통제 가능한 루틴이 되면서, 현장의 피로도가 눈에 띄게 줄었습니다.

검증이 끝나자마자 케이스를 당일에 마무리할 수 있었습니다. 이번 접근이 특별해서라기보다, 필요한 것만 정확히 했다는 점이 더 컸습니다.

배운 점

  • “잔존 프로세스/포트”는 초기화 지연의 단골 원인
  • 재기동 타이밍은 현장 초기화 소요를 기준으로 보수적으로
  • 로그는 첫 에러와 대기구간을 확실히 채증

체크리스트

  • Stop → 잔존/포트 정리 → Start 순서 준수
  • 간격(SLEEP_SEC), 횟수(ITER)는 로그 근거로 조정
  • 모니터링은 “가벼운 정보 + 핵심 지표” 위주로

재발 방지는 결국 기본으로 돌아갑니다. Stop 이후 잔존과 포트를 깔끔하게 정리하고, Start는 서두르지 않습니다. 간격과 반복 수는 로그로 확인한 현실의 초기화 시간을 따라갑니다. 모니터링은 가볍고 명확해야 하며, 실패 시 첫 에러 메시지와 대기 구간을 반드시 남기는 것이 핵심입니다.

내부 표준 문서에는 이번 스크립트와 파라미터 표, 그리고 Before/After 기록 양식을 함께 넣어 공유했습니다. 누가 들어와도 같은 순서로, 같은 결과를 낼 수 있도록요.

운영 자동화/런북 컨설팅이 필요하시면, 상황에 맞는 안전한 파라미터부터 함께 정리해 드립니다.

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