Oracle Data Guard 19c physical standby (Broker 사용; 단일 인스턴스, Oracle Restart, RAC)

운영 중인 19c primary 데이터베이스에 대해 RMAN DUPLICATE … FROM ACTIVE DATABASE로 physical standby를 구축하고 Data Guard Broker에 연결합니다. 결과적으로 redo를 실시간으로 수신·적용하는 standby, SUCCESS 상태의 broker 구성, 검증된 switchover(선택 사항으로 failover/reinstate 테스트와 Fast-Start Failover + observer)를 얻습니다. Primary와 standby는 각각 단일 인스턴스, Oracle Restart 또는 RAC일 수 있습니다. 이미 구성된 환경의 일상 운영과 장애 대응은 Data Guard 운영 가이드를 사용합니다.

구성: Primary (단일 인스턴스 / Oracle Restart / RAC 2–8 노드) + physical standby (단일 인스턴스 / Oracle Restart / RAC) + 선택 사항 observer

시작하기 전에

• Standby …모든 노드…서버…에 primary와 같은 버전, 같은 RU의 Oracle Database 소프트웨어가 설치되어 있습니다(소프트웨어만, 데이터베이스 없음). ORACLE_HOME 경로도 같습니다(…). 운영체제 계열과 endian이 같습니다.… Standby에는 Grid Infrastructure(…cluster…Oracle Restart…)가 같거나 더 새로운 RU로 설치되어 실행 중입니다.…
• Primary 데이터베이스는 Enterprise Edition입니다. Data Guard는 EE에 포함되지만, apply 중에 standby를 열어(read only) 사용하려면 Active Data Guard 라이선스가 필요합니다.
• 모든 서버에서 oracle 사용자의 프로파일에 ORACLE_HOME=…, ORACLE_SID, PATH가 설정되어 있습니다(…primary 노드에서는 …1, …2 ……primary에서는 ……; standby 프로파일은 이 가이드에서 작성함).… Grid가 있는 쪽에서는 grid 사용자의 프로파일에 ORACLE_HOME=…, ORACLE_SID=+ASM…(RAC에서는 +ASM1, +ASM2 …)…이 설정되어 있으며, asmcmd와 lsnrctl은 이 프로파일로 실행됩니다.…
• 모든 서버가 서로를 이름으로 해석하고(DNS 또는 /etc/hosts)…, SCAN 이름(…………, …………)이 DNS에서 3개 주소로 해석되며… …/tcp가 양방향으로 열려 있습니다. 네트워크 대역폭이 redo 생성량을 감당할 수 있습니다…. SYNC에서는 왕복 지연이 가급적 1–2 ms 미만이어야 합니다….
• Standby에 primary와 같은 이름의 ASM 디스크 그룹(…, …)이 mount되어 있고 여유 공간이 충분합니다.
• Standby의 Clusterware/Oracle Restart가 정상입니다…. 모든 standby 노드가 클러스터에 있습니다(olsnodes)….
• Primary에서 모든 인스턴스의 redo thread가 활성화되어 있고(v$thread ENABLED = PUBLIC) thread별 online redo 그룹 수와 크기가 같습니다.
• Standby에 데이터 파일, FRA(… GB), 아카이브 로그를 위한 디스크 공간이 primary만큼 있습니다.
• NTP/chrony로 시각이 동기화되어 있고 시간대가 같습니다.
• Primary에 패스워드 파일이 있고(REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE) SYS 패스워드를 알고 있습니다. 패스워드에 @, /, ", 공백이 없어야 합니다(RMAN/DGMGRL 접속 문자열에서 문제가 됨).
• Primary가 ARCHIVELOG 모드가 아니면 한 번 재시작이 필요하며…(모든 인스턴스가 종료됨)…, 이를 위한 유지보수 시간이 승인되어 있습니다. Primary의 최신 RMAN 백업이 있습니다.
• Observer 서버에 Oracle Client(Administrator 설치 유형, dgmgrl과 mkstore 포함) 또는 Database 소프트웨어가 설치되어 있고, …/tcp로 primary와 standby에 접속할 수 있습니다.

가이드 단계

• 사전 점검 — Primary의 현재 상태 확인
• Primary 준비 — FRA 정의 (없는 경우) · ARCHIVELOG 모드 활성화 (필요한 경우) · Force logging과 Flashback Database 활성화 · Data Guard 파라미터 설정 · Standby redo log 생성 · 패스워드 파일 검증
• Oracle Net (tnsnames, 정적 리스너) — tnsnames.ora 항목 추가 (primary…, 모든 노드…) · 정적 리스너 등록 추가 (primary) · 정적 리스너 등록 추가 (primary 노드 …: …) · 방화벽에서 리스너 포트 개방… (모든 노드)…
• Standby 서버 준비 — Primary의 디렉터리 목록 추출 후 standby로 전송 · 패스워드 파일을 standby로 복사 · 패스워드 파일을 standby로 복사 (Clusterware 등록 정보에서) · oratab과 환경 파일 준비 (standby) · oratab과 환경 파일 준비 (standby 노드 …: …) · 디렉터리 생성 (standby…, 모든 노드…) …
• Standby 생성 (RMAN DUPLICATE)과 Redo Apply — Standby 생성: RMAN DUPLICATE FROM ACTIVE DATABASE · Standby 상태 검증 · Standby redo log가 없으면 생성 (standby) · 임시 pfile 삭제 (standby) · RAC standby: 클러스터 파라미터를 spfile에 기록 · RAC standby: spfile과 패스워드 파일을 ASM으로 이동 …
• Data Guard Broker와 보호 모드 — Broker 구성 파일을 공유 위치로 이동 (primary RAC) · Broker 시작 (primary) · Broker 구성 파일을 공유 위치로 이동 (standby RAC) · Broker 시작 (standby) · Broker 구성 생성 · Apply 인스턴스 지정 (RAC standby) …
• Switchover 테스트 — Switchover 테스트: standby를 primary로 전환 · Switchover 후 상태 확인 · Switchback: 원래 역할로 복원
• Standby의 flashback — Standby에서 Flashback Database 활성화
• Failover와 reinstate 테스트 — Failover 테스트 1/4: primary 장애 모의 · Failover 테스트 2/4: standby로 failover · Failover 테스트 3/4: 이전 primary를 MOUNT로 시작 · Failover 테스트 4/4: 이전 primary를 standby로 복원 (REINSTATE) · Failover 후 원래 역할로 복원
• Fast-Start Failover와 observer — tnsnames.ora 작성 (observer) · Observer용 wallet 생성 · sqlnet.ora에 wallet 지정 (observer) · Wallet으로 연결 테스트 (observer) · Fast-Start Failover 속성 설정 · Observer 시작 스크립트 작성 (observer) …
• 설치 후 작업 — 아카이브 로그 삭제 정책 설정 (primary) · 아카이브 로그 삭제 정책 설정 (standby) · 아카이브 정리 스크립트 작성 (standby…, 모든 노드…) · cron 환경으로 스크립트 수동 테스트 (standby…, 모든 노드…) · cron 작업 정의 (standby…, 모든 노드…) · cron 파일 권한 확인 …