Oracle Database 19c Release Update (RU) 적용

단일 인스턴스 또는 Oracle Restart(Grid Infrastructure + ASM) 19c 데이터베이스에 분기별 Release Update를 적용합니다: OPatch 업데이트, 충돌 및 공간 사전 점검, ORACLE_HOME 백업과 guaranteed restore point, opatch apply(Oracle Restart는 opatchauto), 선택 사항인 OJVM RU, datapatch, utlrp 및 검증. 다운타임을 줄이는 out-of-place 방식(새 home에 설치 후 전환)과 각 방식별 롤백(rollback) 단계도 포함합니다. RAC를 선택하면 노드별 rolling 적용을 위해 RAC 가이드로 안내합니다.

구성: 서버 1대 (단일 인스턴스 또는 Oracle Restart), RAC는 rolling patch 가이드

시작하기 전에

• … 아래의 패치 파일: …GI RU ……DB RU ………, OJVM RU ……, OPatch ……, 새 home용 기본 설치 파일 LINUX.X64_193000_db_home.zip…. 패치 번호를 MOS에서 확인하고 RU README를 처음부터 끝까지 읽으십시오(최소 OPatch 버전, 알려진 문제, 추가 단계가 README에 있습니다).
• MOS 555.1에서 권장하는 one-off 패치의 새 RU용 버전을 내려받았고, 현재 home의 one-off가 새 RU와 충돌하는지 파악했습니다(충돌하는 one-off는 RU 기반으로 만든 새 버전이 필요합니다).
• 현재 패치 레벨과 데이터베이스 상태를 기록했으며, 모든 구성 요소가 VALID입니다.
• ORACLE_HOME이 있는 파일 시스템에 최소 15GB(OPatch가 이전 파일을 .patch_storage에 보관), … 디렉터리에 home 크기만큼…, 새 home용으로 최소 15GB…의 여유 공간이 있습니다.
• restore point를 위해 데이터베이스가 ARCHIVELOG 모드이고 FRA에 충분한 여유 공간이 있습니다(패치 중 생성되는 flashback log용).
• 최근 24시간 이내에 성공하고 검증된 RMAN 백업이 있습니다.
• 유지보수 윈도가 승인되었고, 애플리케이션 팀이 다운타임을 알고 있으며, 모니터링(EM/agent)은 blackout 상태이고, 예약 작업(cron, DBMS_SCHEDULER)은 중지되었습니다.
• 가능하면 서버(VM) snapshot을 받았습니다.
• 데이터베이스에 Data Guard standby가 있으면 패치 순서를 계획했습니다: standby의 home을 먼저 패치하고(Standby-First, MOS 1265700.1) primary는 나중에 패치하며, datapatch는 primary에서만 실행합니다. standby가 없으면 이 항목은 건너뜁니다.
• 클러스터가 정상이고 모든 노드에서 인스턴스가 open 상태입니다. RAC 패치의 자세한 선행 조건은 Oracle RAC 19c rolling Release Update 가이드에 있습니다.
• Standby-First 조건(MOS 1265700.1): RU README에 'Data Guard Standby-First Installable'이 명시되어 있고(Release Update는 해당하며, one-off는 README를 별도로 확인)…, 19c OJVM RU는 무조건 Standby-First가 아니며(아래 참고 사항 참조)…, primary와 standby의 패치 차이는 전환 기간(짧게) 동안만 유지하고, datapatch는 모든 standby 와 primary를 패치한 뒤 primary에서만 한 번 실행합니다.… 이 primary의 모든 standby에 새 RU 바이너리가 설치되어 있고 standby는 apply를 계속하고 있습니다.…

가이드 단계

• RAC: 환경 검증 후 rolling patch 가이드로 이동 — 클러스터와 노드 검증 · RAC rolling patch 가이드 적용
• 사전 점검 — 현재 패치 레벨 확인 (DB home) · 현재 패치 레벨 확인 (Grid home) · 데이터베이스 상태와 SQL 패치 이력 확인 · standby의 역할과 apply 상태 확인 (Data Guard standby) · Data Guard 상태 확인 (primary) · standby에 새 RU가 설치되었는지 확인 …
• 백업과 복귀 지점 — RMAN 백업 확인 · Redo Apply 중지 (Data Guard standby) · Guaranteed restore point 생성 · Guaranteed restore point 생성 (standby)
• 적용: in-place (opatch apply) — 데이터베이스와 리스너 중지 · ORACLE_HOME과 인벤토리 백업 · RU 적용 (opatch apply) · OJVM RU 적용 · 리스너와 데이터베이스 기동 · 리스너와 standby를 MOUNT로 기동, apply 시작
• 적용: in-place (Oracle Restart, opatchauto) — Oracle Restart 중지 (백업용) · Grid home, DB home, 인벤토리 백업 · Oracle Restart 기동 · GI RU 적용 (opatchauto) · OJVM RU를 DB home에 적용 · Redo Apply 시작 (Data Guard standby)
• 적용: out-of-place (새 home) — 새 home 디렉터리 생성 · 기본 소프트웨어 압축 해제와 OPatch 업데이트 · 새 home용 response file 준비 · RU를 포함한 새 home 설치 · root.sh 실행 (새 home) · 이전 home과 새 home의 패치 비교 …
• SQL 수준 패치 (datapatch) — datapatch 실행 · invalid 객체 재컴파일 (utlrp) · standby에서 datapatch를 실행하지 마십시오 · SQL 변경이 standby로 전달되는지 확인
• 검증 — 바이너리 패치 레벨 검증 · 바이너리 패치 레벨 검증 (Grid home) · SQL 패치 레지스트리와 객체 검증 · standby에서 새 바이너리로 apply가 계속되는지 검증 · alert log 확인 · 애플리케이션 테스트 수행 …
• 마무리 — Restore point 삭제 · Restore point 삭제 (standby) · 정리
• 롤백 (필요한 경우에만) — 데이터베이스와 리스너 중지 · 패치 롤백 (opatch rollback) · 패치 롤백 (opatchauto rollback) · 이전 home으로 복귀 · 이전 바이너리로 standby를 MOUNT로 기동하고 apply 시작 · 기동과 SQL 패치 롤백 (datapatch) …