Oracle RAC 19c rolling Release Update (opatchauto)

운영 중인 2–8 노드 RAC 19c 클러스터에 분기별 GI Release Update를 무중단(rolling)으로 적용합니다: OPatch 업데이트, opatchauto analyze를 통한 충돌 검사, OCR 백업과 복귀 지점, 서비스를 재배치하면서 노드별 적용, 한 노드에서 datapatch 완료, 검증, 필요 시 rollback. 단일 인스턴스와 Oracle Restart에는 "Oracle Database 19c Release Update (RU) 적용" 가이드를 사용하십시오. OJVM RU는 rolling이 아니며 별도의 다운타임이 필요합니다.

구성: 기존 2–8 노드 RAC 19c

시작하기 전에

• RU의 README를 읽었습니다: 최소 OPatch 버전, 알려진 문제, 선행 one-off, 별도의 OJVM 패치(OJVM RU는 rolling이 아니며 별도의 다운타임이 필요). My Oracle Support에서 "Oracle Database 19c Important Recommended One-off Patches"(Doc ID 555.1)와 RU 다운로드 가이드(Doc ID 2118136.2)를 이 RU 기준으로 확인했습니다.
• 각 노드의 … 아래에 …와 p6880880_190000_Linux-x86-64.zip(최신 OPatch)이 있으며, 파일은 MOS의 SHA-256 값으로 검증했습니다.
• GI 및 DB home이 있는 파일 시스템에 최소 20 GB(README의 값 참조), /tmp에 최소 1 GB의 여유 공간이 있습니다. …… 디렉터리에 home 백업을 위한 공간이 있습니다.…
• 클러스터가 정상입니다: 모든 노드에서 CRS online, OFFLINE 상태로 남은 리소스 없음, 모든 인스턴스가 open 상태. 패치 중 한 노드가 내려가 있어도 나머지 노드가 전체 부하를 감당할 수 있는 용량입니다.
• 애플리케이션 서비스는 각 노드에서 다른 인스턴스로 전환될 수 있도록 정의되어 있고(preferred/available 또는 uniform), 애플리케이션은 SCAN + 서비스 이름으로 접속합니다(FAN/AC가 있으면 세션이 끊김 없이 이동합니다).
• 데이터베이스의 최신 RMAN 백업과 아카이브 로그가 있고 OCR 백업을 받았습니다. 유지보수 시간대가 승인되었고 Enterprise Manager에서 blackout을 설정했습니다.
• 다른 opatch/opatchauto 작업이 실행 중이지 않으며 home에 잠금 파일이 없습니다.
• 데이터베이스에 Data Guard standby가 있으면 standby 클러스터(또는 서버)를 먼저 패치합니다(Standby-First, MOS 1265700.1). primary는 그 후에 이 가이드로 패치하며 datapatch는 primary에서만 실행합니다.

가이드 단계

• 사전 점검 — 현재 패치 레벨 기록 (Clusterware) · home의 패치 목록 조회 (…) · SQL 패치 이력과 invalid 객체 기록
• 준비: RU, OPatch 및 분석 — RU 압축 해제 (…) · GI home의 OPatch 업데이트 (…) · DB home의 OPatch 업데이트 (…) · 충돌 및 선행 조건 분석 (…)
• 백업과 복귀 지점 — OCR 수동 백업 · Guaranteed restore point 생성 · GI 및 DB home 백업 (…)
• 검증 및 마무리 — PDB가 open 상태인지 확인 · datapatch를 한 노드에서만 실행 · SQL 패치 레지스트리 검증 · invalid 객체 컴파일 (필요 시) · 클러스터 패치 상태 검증 · 서비스를 preferred 배치로 복귀 …
• 롤백 (필요한 경우에만) — Rollback: opatchauto rollback 실행 (…) · Rollback: datapatch 실행 (한 노드) · Rollback: 결과 검증 · 최후 수단: 데이터베이스를 restore point로 되돌리기