Oracle RAC 19c Rolling Release Update (opatchauto)

Spielt ein vierteljährliches GI Release Update ohne Ausfallzeit (rolling) in einen laufenden RAC-19c-Cluster mit 2–8 Nodes ein: OPatch-Aktualisierung, Konfliktprüfung mit opatchauto analyze, OCR-Backup und Rückfallpunkt, Einspielen Node für Node mit verlagerten Services, Abschluss von datapatch auf einem einzigen Node, Verifizierung und bei Bedarf Rollback. Für Single Instance und Oracle Restart verwende den Guide „Oracle Database 19c Release Update (RU) einspielen“; das OJVM RU ist nicht rolling und erfordert eine separate Ausfallzeit.

Topologie: Bestehender RAC 19c mit 2–8 Nodes

Vor dem Start

• Die README des RU ist gelesen: minimale OPatch-Version, bekannte Probleme, vorausgesetzte One-off-Patches, der separate OJVM-Patch (das OJVM RU ist nicht rolling und erfordert eine separate Ausfallzeit). „Oracle Database 19c Important Recommended One-off Patches“ (Doc ID 555.1) und der RU-Download-Leitfaden (Doc ID 2118136.2) in My Oracle Support sind für dieses RU geprüft.
• Auf jedem Node liegen unter … … und p6880880_190000_Linux-x86-64.zip (aktuelles OPatch); die Dateien sind gegen die SHA-256-Werte auf MOS geprüft.
• Das Dateisystem mit den GI und DB Homes hat mindestens 20 GB frei (prüfe den Wert in der README), /tmp mindestens 1 GB. …In … ist Platz für die Home-Backups.…
• Der Cluster ist gesund: CRS auf allen Nodes online, keine Ressource OFFLINE, alle Instances geöffnet. Während ein Node beim Patchen heruntergefahren ist, können die übrigen Nodes die gesamte Last tragen.
• Die Anwendungs-Services sind so definiert, dass sie auf jedem Node auf eine andere Instance wechseln können (preferred/available oder uniform), und die Anwendungen verbinden sich über SCAN + Servicename (mit FAN/AC werden Sessions ohne Unterbrechung verlagert).
• Es gibt ein aktuelles RMAN-Backup der Datenbank samt Archive Logs; ein OCR-Backup ist erstellt. Das Wartungsfenster ist freigegeben; in Enterprise Manager ist ein Blackout gesetzt.
• Es läuft kein anderer opatch-/opatchauto-Vorgang; in den Homes gibt es keine Lock-Dateien.
• Hat die Datenbank eine Data-Guard-Standby, wird der Standby-Cluster (bzw. -Server) zuerst gepatcht (Standby-First, MOS 1265700.1); die Primary wird danach mit diesem Guide gepatcht, und datapatch läuft nur auf der Primary.

Phasen der Anleitung

• Vorabprüfungen — Aktuellen Patch-Level festhalten (Clusterware) · Patches in den Homes auflisten (…) · SQL-Patch-Historie und ungültige Objekte festhalten
• Vorbereitung: RU, OPatch und Analyse — RU entpacken (…) · OPatch im GI Home aktualisieren (…) · OPatch im DB Home aktualisieren (…) · Konflikt- und Voraussetzungsanalyse durchführen (…)
• Backup und Rückfallpunkt — Manuelles OCR-Backup erstellen · Guaranteed Restore Point anlegen · GI und DB Homes sichern (…)
• Verifizierung und Abschluss — Sicherstellen, dass die PDBs geöffnet sind · datapatch nur auf einem Node ausführen · SQL Patch Registry verifizieren · Ungültige Objekte kompilieren (bei Bedarf) · Patch-Zustand des Clusters verifizieren · Services auf die bevorzugte Verteilung zurücksetzen …
• Rollback (nur bei Bedarf) — Rollback: opatchauto rollback ausführen (…) · Rollback: datapatch ausführen (ein Node) · Rollback: Ergebnis verifizieren · Letzter Ausweg: Datenbank auf den Restore Point zurücksetzen