Oracle Database 19c Release Update (RU) einspielen

Vierteljährliches Release Update für eine 19c-Datenbank als Single Instance oder unter Oracle Restart (Grid Infrastructure + ASM): OPatch-Aktualisierung, Vorabprüfungen auf Konflikte und Platz, Sicherung des ORACLE_HOME und Guaranteed Restore Point, opatch apply (unter Oracle Restart opatchauto), optional das OJVM RU, datapatch, utlrp und Verifizierung. Enthalten sind der Out-of-Place-Weg, der die Ausfallzeit verkürzt (Installation in ein neues Home und Umschalten), sowie Rollback-Schritte für jeden Weg. Wird RAC gewählt, verweist der Guide für das Rolling-Einspielen Node für Node auf den RAC-Guide.

Topologie: 1 Server (Single Instance oder Oracle Restart); für RAC der Rolling-Patch-Guide

Vor dem Start

• Patch-Dateien unter …: …GI RU ……DB RU ………, OJVM RU ……, OPatch …… sowie die Basis-Installationsdatei für das neue Home, LINUX.X64_193000_db_home.zip…. Prüfe die Patch-Nummer in MOS und lies die README des RU vollständig (minimale OPatch-Version, bekannte Probleme und zusätzliche Schritte stehen in der README).
• Die zum neuen RU passenden Versionen der in MOS 555.1 empfohlenen One-off-Patches sind heruntergeladen; es ist bekannt, ob die One-offs im aktuellen Home mit dem neuen RU in Konflikt stehen (ein kollidierendes One-off braucht eine neue, auf dem RU aufbauende Version).
• Aktueller Patch Level und Datenbankzustand sind dokumentiert; alle Komponenten VALID.
• Freier Platz: mindestens 15 GB im Dateisystem des ORACLE_HOME (OPatch bewahrt die alten Dateien in .patch_storage auf), so viel wie die Home-Größe in …… und mindestens 15 GB für das neue Home….
• Für den Restore Point ist die Datenbank im ARCHIVELOG-Modus, und die FRA hat genug freien Platz (für die während des Patchens erzeugten Flashback Logs).
• Es gibt ein erfolgreiches, getestetes RMAN-Backup aus den letzten 24 Stunden.
• Das Wartungsfenster ist genehmigt; die Anwendungsteams wissen von der Ausfallzeit; das Monitoring (EM/Agent) ist im Blackout; geplante Jobs (cron, DBMS_SCHEDULER) sind gestoppt.
• Wenn möglich, wurde ein Snapshot des Servers (VM) erstellt.
• Hat die Datenbank eine Data-Guard-Standby, ist die Patch-Reihenfolge geplant: Zuerst wird das Home der Standby gepatcht (Standby-First, MOS 1265700.1), die Primary später, und datapatch läuft nur auf der Primary. Ohne Standby entfällt dieser Punkt.
• Der Cluster ist gesund, und auf allen Nodes sind die Instances geöffnet; die ausführlichen Voraussetzungen für das RAC-Patching stehen im Guide Oracle RAC 19c rolling Release Update.
• Voraussetzungen für Standby-First (MOS 1265700.1): In der README des RU steht „Data Guard Standby-First Installable“ (Release Updates erfüllen das; bei One-offs die README gesondert prüfen)…; das 19c OJVM RU ist nicht uneingeschränkt Standby-First (siehe Hinweis unten)…; der Patch-Unterschied zwischen Primary und Standby besteht nur während der (kurzen) Übergangszeit; datapatch läuft, nachdem alle Standbys und die Primary gepatcht sind, ein einziges Mal und nur auf der Primary.… Auf allen Standbys dieser Primary sind die Binaries des neuen RU installiert, und die Standbys wenden weiterhin Redo an.…

Phasen der Anleitung

• RAC: Umgebung verifizieren und zum Rolling-Patch-Guide wechseln — Cluster und Nodes verifizieren · RAC-Rolling-Patch-Guide anwenden
• Vorabprüfungen — Aktuellen Patch Level prüfen (DB Home) · Aktuellen Patch Level prüfen (Grid Home) · Datenbankzustand und SQL-Patch-Historie prüfen · Rolle und Apply-Status der Standby prüfen (Data-Guard-Standby) · Data-Guard-Status prüfen (Primary) · Prüfen, dass das neue RU auf den Standbys installiert ist …
• Backup und Rückfallpunkt — RMAN-Backups prüfen · Redo Apply stoppen (Data-Guard-Standby) · Guaranteed Restore Point erstellen · Guaranteed Restore Point erstellen (Standby)
• Einspielen: In-Place (opatch apply) — Datenbank und Listener stoppen · ORACLE_HOME und Inventory sichern · RU einspielen (opatch apply) · OJVM RU einspielen · Listener und Datenbank starten · Listener und Standby im MOUNT-Zustand starten, Apply aktivieren
• Einspielen: In-Place (Oracle Restart, opatchauto) — Oracle Restart stoppen (für die Sicherung) · Grid Home, DB Home und Inventory sichern · Oracle Restart starten · GI RU einspielen (opatchauto) · OJVM RU auf das DB Home einspielen · Redo Apply starten (Data-Guard-Standby)
• Einspielen: Out-of-Place (neues Home) — Verzeichnis für das neue Home erstellen · Basissoftware entpacken und OPatch aktualisieren · Response File für das neue Home vorbereiten · Neues Home mit dem RU installieren · root.sh ausführen (neues Home) · Patches in altem und neuem Home vergleichen …
• Patch auf SQL-Ebene (datapatch) — datapatch ausführen · Ungültige Objekte kompilieren (utlrp) · datapatch nicht auf der Standby ausführen · Prüfen, dass die SQL-Änderungen die Standbys erreichen
• Verifizierung — Patch Level der Binaries verifizieren · Patch Level der Binaries verifizieren (Grid Home) · SQL-Patch-Registry und Objekte verifizieren · Auf der Standby prüfen, dass Apply mit den neuen Binaries weiterläuft · Alert Log prüfen · Anwendungstests durchführen …
• Abschluss — Restore Point löschen · Restore Point löschen (Standby) · Aufräumen
• Rollback (nur bei Bedarf) — Datenbank und Listener stoppen · Patches zurücknehmen (opatch rollback) · Patches zurücknehmen (opatchauto rollback) · Zum alten Home zurückwechseln · Standby mit den alten Binaries im MOUNT-Zustand starten und Apply starten · Starten und SQL-Patches zurücknehmen (datapatch) …