Oracle Data Guard 일상 운영 및 장애 시나리오 (19c / 23ai)
Oracle난이도: 고급소요 시간: 5분(점검) – 4시간(재구축)이미 구성된 Data Guard(physical standby) 환경의 일상 운영 및 장애 복구 runbook입니다. 최초 구성은 Data Guard 설치 가이드를 사용합니다. 무엇을 해야 할지 확실하지 않으면 '상태 및 지연 점검'부터 시작합니다. 읽기 전용 진단이 알맞은 시나리오(계획된 switchover, failover, 이전 primary reinstate, 아카이브 갭, RECOVER … FROM SERVICE를 이용한 롤 포워드, standby 재구축, snapshot standby, apply/read-only, 보호 모드/FSFO/observer, datafile 및 redo log 작업, standby에서의 RMAN 백업)로 안내합니다. 모든 시나리오는 진단 → 안전장치 → 실행 → 검증 → 후속 조치 순서를 따르며, broker 사용(DGMGRL)과 broker 미사용(SQL) 경로를 단일 인스턴스 / Oracle Restart / RAC 차이와 함께 제시합니다.
구성: Primary(단일 인스턴스 / Oracle Restart / RAC) + physical standby(단일 인스턴스 / Oracle Restart / RAC) + 선택 사항 observer
시나리오
- 상태 및 지연 점검 (모두 정상인가?) — 읽기 전용: 구성, transport/apply lag, 아카이브 갭, 프로세스, alert log를 확인하며 아무것도 변경하지 않습니다. 무엇을 해야 할지 확실하지 않으면 여기서 시작합니다. 마지막 단계가 출력 결과에 따라 알맞은 시나리오를 알려 줍니다.
- 계획된 switchover (역할 교체) — Primary와 standby가 정상이고 역할을 계획적으로 교체하려는 경우입니다(유지보수, DR 훈련, 역할 원복). 데이터 손실은 없으며 애플리케이션은 몇 분간 중단됩니다. Primary에 접속할 수 있는 한 역할 전환에는 항상 이 시나리오를 선택합니다.
- Primary 상실: standby로 failover — Primary에 접속할 수 없고 복구되지 않는 경우입니다(서버, 스토리지, 사이트 상실). standby가 primary가 됩니다. 되돌릴 수 없습니다. MaxPerformance에서는 마지막 몇 초간의 데이터가 손실될 수 있고, 이전 primary는 이후 reinstate 또는 재구축이 필요합니다. Primary에 아직 접속할 수 있다면 switchover를 선택합니다.
- Failover 후 이전 primary를 standby로 복귀 (reinstate) — Failover가 수행되었고 이전 primary 서버가 다시 살아난 경우입니다. Flashback Database가 활성화되어 있으면 재구축 없이 새 primary의 standby로 만듭니다. 새 primary는 계속 열려 있습니다. Flashback이 비활성화되어 있거나 flashback 기간이 부족하면 진단 단계가 재구축으로 안내합니다.
- 아카이브 갭(gap): standby가 누락된 아카이브 로그를 기다림 — v$archive_gap이 행을 반환하거나 alert log에 FAL/gap 메시지가 있고, apply가 특정 sequence에서 멈춰 있습니다. 데이터베이스는 열린 상태를 유지합니다. 누락된 아카이브 로그가 어디에도 없으면 폼에서 선택하여 롤 포워드 경로로 전환합니다.
- Standby가 크게 뒤처졌거나 아카이브 로그가 없음: 롤 포워드 (RECOVER FROM SERVICE) — 갭에 해당하는 아카이브 로그가 어디에도 없거나, NOLOGGING 작업으로 standby가 손상되었거나, standby가 며칠씩 뒤처진 경우입니다. standby를 재구축하지 않고 primary에서 증분 방식으로 동기화합니다(18c+).
- Standby를 처음부터 재구축 — Reinstate(flashback 없음)와 롤 포워드가 모두 불가능하거나, standby의 파일/컨트롤 파일이 상실된 경우입니다. standby를 삭제하고 DUPLICATE로 다시 생성합니다. Primary는 열린 상태를 유지하지만 재구축이 끝날 때까지 보호되지 않습니다(다른 standby가 없는 경우).
- Snapshot standby로 전환 / 원복 (테스트용 쓰기 가능 복사본) — Standby를 일시적으로 읽기-쓰기로 열어 테스트한 뒤 변경 사항을 버리고 physical standby로 돌아가려는 경우입니다. Primary는 영향을 받지 않고 redo도 계속 수신되지만, snapshot standby 상태인 동안 이 standby는 failover 준비 상태가 아닙니다.
- Redo Apply 중지 / 시작, apply 인스턴스 변경, read-only 오픈 — 유지보수를 위해 MRP를 중지하거나 재시작하거나, RAC standby에서 apply를 다른 인스턴스로 옮기거나, 리포트용으로 standby를 열려는 경우입니다(Active Data Guard 라이선스 주의).
- 보호 모드, Fast-Start Failover, observer — MaxPerformance / MaxAvailability / MaxProtection 간 전환, FSFO 활성화/비활성화 또는 observer 관리를 하려는 경우입니다.
- Datafile, redo log, standby redo log 추가 / UNNAMED 파일 — Primary에 datafile 또는 redo log를 추가해야 하거나, standby에 UNNAMED 파일이 생겼거나(ORA-01111/ORA-01274), standby redo log가 누락된 경우입니다.
- Standby에서 RMAN 백업 수행 — Primary의 백업 부하를 덜기 위해 RMAN 백업을 standby에서 실행하고, 이에 맞춰 아카이브 로그 삭제 정책을 설정하려는 경우입니다.
시작하기 전에
- 모든 서버에서 oracle 사용자의 프로파일에 ORACLE_HOME=…, ORACLE_SID(…RAC에서는 노드별 …1, …2 …………), PATH가 설정되어 있고 sqlplus, rman…, dgmgrl…이 동작합니다. 구성은 Data Guard 설치 가이드 또는 이와 동등한 방식으로 구축되어 있습니다(TNS alias …, …, 정적 _DGMGRL 리스너 등록, 동일한 패스워드 파일).
- 역할이 입력값과 일치함을 확인했습니다. 현재 …가 primary, …가 physical standby입니다. 그렇지 않으면(예: 이전에 switchover를 수행한 경우) 입력값의 이름을 서로 바꿉니다.
- SYS 패스워드를 알고 있습니다(역할 전환, 원격 인스턴스 재시작, RMAN FROM SERVICE에는 패스워드 인증 연결이 필요). 패스워드에 @, /, ", 공백이 없습니다.
- 라이선스: Data Guard는 Enterprise Edition에 포함됩니다. apply 실행 중에 standby를 오픈하여 사용하는 것, standby의 block change tracking, Far Sync에는 Active Data Guard 라이선스가 필요합니다. Snapshot standby와 apply를 끈 상태의 read-only 오픈은 라이선스가 필요 없습니다.
- 변경이 승인된 유지보수 윈도우 내에 있으며 애플리케이션 및 모니터링 팀에 공지했습니다…(연결이 몇 분간 끊김)….
- Failover 결정은 권한 있는 담당자가 내렸으며, 이전 primary가 다시 오픈되지 않음(split-brain)이 보장됩니다. 서버가 꺼져 있거나 네트워크에서 분리되었거나 인스턴스가 MOUNT 상태로 유지됩니다.
가이드 단계
- 상태: 구성, 지연, 프로세스 (읽기 전용) — Broker 구성과 역할 전환 준비 상태 표시 · SQL로 primary 측 점검 · SQL로 standby 측 점검 · Alert log에서 Data Guard 오류 검색 · 결과 해석 및 알맞은 시나리오 선택
- 1. 진단: switchover 준비가 되었는가? — 준비 상태 확인 (VALIDATE) · 준비 상태 확인 (SWITCHOVER … VERIFY) · Standby 지연 확인
- 2. 안전장치 — 현재 구성 저장 (primary) · 현재 구성 저장 (standby)
- 3. 실행: switchover — Switchover: …를 primary로 (broker) · Switchover 시작 (primary → standby) · 새 primary 오픈 (…) · Clusterware 역할 갱신 (새 primary) · 다른 인스턴스 오픈 (새 primary 노드 …: …) · 이전 primary를 standby로 MOUNT (…) …
- 4. 검증 — 새 역할과 구성 검증 · 새 standby의 apply와 지연 확인
- 5. 후속 조치 — 애플리케이션, 작업, 모니터링 점검
- 1. 진단: failover가 정말 필요한가? — Primary 접속 마지막 시도 (standby에서) · Standby 상태와 예상 데이터 손실 평가 · Broker가 보는 상태 표시 (standby에서)
- 2. 안전장치와 남은 redo — Standby의 현재 설정 저장 · 이전 primary를 MOUNT하고 남은 redo 전송 (FLUSH REDO) · 누락된 아카이브 로그 수동 복사 (broker 없음, 가능한 경우)
- 3. 실행: failover — Failover: …를 primary로 (broker) · Redo Apply 중지 및 failover 수행 (SQL) · 새 primary 오픈 (SQL) · Clusterware 역할 갱신 (새 primary) · 다른 인스턴스 오픈 (새 primary 노드 …: …)
- 4. 검증 — 새 primary 검증
- 5. 후속 조치 — 새 primary의 전체 백업 수행 · 이전 primary가 돌아오면: 오픈하지 말 것
- 애플리케이션 서비스 (역할 기반) — … 측에 서비스 정의 및 시작 (Clusterware) · … 측에 서비스 정의 (Clusterware) · 서비스와 역할 트리거 정의 (Grid 없음) · 두 주소로 클라이언트 연결 디스크립터 구성
- 1. 진단: reinstate가 가능한가? — 새 primary와 역할 전환 SCN 확인 · Broker 상태 표시 (새 primary) · 이전 primary를 MOUNT하고 flashback 기간 점검
- 2. 안전장치 — 이전 primary의 컨트롤 파일과 파라미터 저장
- 3. 실행: reinstate — 이전 primary reinstate (broker) · 다른 인스턴스 시작 (이전 primary, RAC) · Flashback 후 physical standby로 전환 (SQL) · 새 primary에서 … 대상 활성화 (SQL) · Redo Apply 시작 및 역할 전환 레코드 통과 (SQL)
- 4. 검증 — 구성 검증 · 이전 primary(새 standby)의 apply 검증
- 5. 후속 조치 — 원래 역할로 복귀(선택)하고 근본 원인 해소
- 1. 진단: 갭은 어디에 있고 아카이브 로그는 존재하는가? — Standby의 갭과 프로세스 표시 · FAL 연결과 alert log 확인 (standby) · 누락된 아카이브 로그가 primary에 남아 있는가? · 누락된 아카이브 로그가 RMAN 백업에 있는가?
- 2. 안전장치 — Standby FRA 여유 공간 확인
- 3. 실행: 누락된 아카이브 로그 가져오기 및 등록 — 아카이브 로그가 백업에만 있는 경우: primary에 복원 · 누락된 아카이브 로그를 파일 시스템에 복사하여 standby로 전송 (primary) · Standby에 아카이브 로그 등록 · Redo Apply 재시작 (standby)
- 4. 검증 — 갭 해소 확인 (standby)
- 5. 후속 조치 — 임시 사본 삭제 · 근본 원인 해소
- 1. 진단: standby가 얼마나 뒤처졌는가? — Standby의 SCN과 상태 표시 · Primary의 NOLOGGING 작업과 COMPATIBLE 값 확인
- 2. 안전장치 — Standby 컨트롤 파일과 spfile 백업
- 3. 실행: standby 롤 포워드 — Redo Apply 중지 (standby) · Standby MOUNT… (1번 인스턴스만)… · Primary에서 standby 롤 포워드 (RECOVER STANDBY DATABASE FROM SERVICE) · 다른 standby 인스턴스 시작 · Standby redo log와 flashback 상태 확인 · Redo Apply 시작 (standby)
- 4. 검증 — 지연 해소 확인
- 5. 후속 조치 — 근본 원인 해소
- 1. 진단: 재구축이 정말 필요한가? — 구성과 primary 상태 표시
- 2. 안전장치 — Standby 구성 파일 보관
- 3. 실행: 삭제 및 재구축 — Broker 구성에서 standby 제거 · Primary에서 standby 대상 보류 (DEFER) · 이전 standby 데이터베이스 삭제 · 남은 broker, init, 패스워드 파일 정리 · 이전 init 파일 보관 처리 (standby 노드 …: …) · 설치 가이드로 standby 재생성 …