Oracle RAC 19c : Release Update en rolling (opatchauto)

Applique une Release Update GI trimestrielle à un cluster RAC 19c de 2 à 8 nœuds en fonctionnement, sans interruption (rolling) : mise à jour d'OPatch, contrôle des conflits avec opatchauto analyze, sauvegarde de l'OCR et point de retour, application nœud par nœud avec déplacement des services, exécution de datapatch sur un seul nœud, vérification et rollback si nécessaire. Pour une instance unique et Oracle Restart, utilisez le guide "Appliquer une Release Update (RU) Oracle Database 19c" ; la RU OJVM n'est pas rolling et exige une interruption séparée.

Topologie: RAC 19c existant de 2 à 8 nœuds

Avant de commencer

• Le README de la RU a été lu : version minimale d'OPatch, problèmes connus, one-offs prérequis, patch OJVM séparé (la RU OJVM n'est pas rolling et exige une interruption séparée). Sur My Oracle Support, "Oracle Database 19c Important Recommended One-off Patches" (Doc ID 555.1) et le guide de téléchargement des RU (Doc ID 2118136.2) ont été vérifiés pour cette RU.
• Sur chaque nœud, … et p6880880_190000_Linux-x86-64.zip (OPatch récent) se trouvent sous … ; les fichiers ont été vérifiés avec les valeurs SHA-256 publiées sur MOS.
• Le système de fichiers des GI et DB homes dispose d'au moins 20 Go libres (voir la valeur du README) et /tmp d'au moins 1 Go. …… a la place nécessaire pour les sauvegardes des homes.…
• Le cluster est sain : CRS online sur tous les nœuds, aucune ressource restée OFFLINE, toutes les instances ouvertes. Pendant le patch, lorsqu'un nœud est arrêté, les autres ont la capacité de porter toute la charge.
• Les services applicatifs sont définis de façon à pouvoir basculer sur une autre instance depuis chaque nœud (preferred/available ou uniform) et les applications se connectent par SCAN + nom de service (avec FAN/AC, les sessions sont déplacées sans interruption).
• La base dispose d'une sauvegarde RMAN récente et de ses archive logs ; une sauvegarde de l'OCR a été prise. La fenêtre de maintenance est validée ; un blackout est posé dans Enterprise Manager.
• Aucune autre opération opatch/opatchauto n'est en cours ; aucun fichier de verrou dans les homes.
• Si la base a un standby Data Guard, le cluster (ou serveur) standby est patché en premier (Standby-First, MOS 1265700.1) ; le primary est patché ensuite avec ce guide et datapatch ne s'exécute que sur le primary.

Phases du guide

• Contrôles préalables — Enregistrer le niveau de patch actuel (Clusterware) · Lister les patchs des homes (…) · Enregistrer l'historique des patchs SQL et les objets invalides
• Préparation : RU, OPatch et analyse — Extraire la RU (…) · Mettre à jour OPatch dans le GI home (…) · Mettre à jour OPatch dans le DB home (…) · Lancer l'analyse des conflits et des prérequis (…)
• Sauvegarde et point de retour — Sauvegarder manuellement l'OCR · Créer un guaranteed restore point · Sauvegarder les GI et DB homes (…)
• Vérification et finalisation — S'assurer que les PDB sont ouvertes · Exécuter datapatch sur un seul nœud · Vérifier le registre des patchs SQL · Recompiler les objets invalides (si nécessaire) · Vérifier l'état de patch du cluster · Remettre les services sur leurs instances preferred …
• Retour arrière (seulement si nécessaire) — Rollback : lancer opatchauto rollback (…) · Rollback : exécuter datapatch (un seul nœud) · Rollback : vérifier le résultat · Dernier recours : ramener la base au restore point