Appliquer une Release Update (RU) Oracle Database 19c

Application d'une Release Update trimestrielle sur une base 19c mono-instance ou Oracle Restart (Grid Infrastructure + ASM) : mise à jour d'OPatch, contrôles préalables de conflits et d'espace, sauvegarde de l'ORACLE_HOME et guaranteed restore point, opatch apply (opatchauto pour Oracle Restart), OJVM RU en option, datapatch, utlrp et vérification. Le guide inclut la voie out-of-place qui réduit l'interruption (installation dans un nouveau home puis bascule) et les étapes de retour arrière (rollback) pour chaque voie. Si RAC est sélectionné, il renvoie au guide RAC pour l'application rolling nœud par nœud.

Topologie: 1 serveur (mono-instance ou Oracle Restart) ; pour RAC, le guide de rolling patch

Avant de commencer

• Fichiers de patch sous … : …GI RU ……DB RU ………, OJVM RU ……, OPatch …… et le fichier d'installation de base du nouveau home, LINUX.X64_193000_db_home.zip…. Vérifiez le numéro de patch dans MOS et lisez le README de la RU en entier (la version minimale d'OPatch, les problèmes connus et les étapes supplémentaires y figurent).
• Les versions des one-off patches recommandés dans MOS 555.1 correspondant à la nouvelle RU sont téléchargées ; on sait si les one-offs du home actuel sont en conflit avec la nouvelle RU (un one-off en conflit nécessite une nouvelle version construite sur la RU).
• Le niveau de patch actuel et l'état de la base sont consignés ; tous les composants sont VALID.
• Il y a au moins 15 Go libres sur le système de fichiers de l'ORACLE_HOME (OPatch conserve les anciens fichiers dans .patch_storage), l'équivalent de la taille du home dans ……, et au moins 15 Go pour le nouveau home….
• Pour le restore point, la base est en mode ARCHIVELOG et la FRA dispose d'assez d'espace libre (pour les flashback logs générés pendant le patch).
• Il existe une sauvegarde RMAN réussie et testée de moins de 24 heures.
• La fenêtre de maintenance est validée ; les équipes applicatives sont informées de l'interruption ; la supervision (EM/agent) est en blackout ; les tâches planifiées (cron, DBMS_SCHEDULER) sont arrêtées.
• Si possible, un snapshot du serveur (VM) a été pris.
• Si la base a une standby Data Guard, l'ordre de patch est planifié : le home de la standby est patché en premier (Standby-First, MOS 1265700.1), la primary est patchée ensuite et datapatch ne s'exécute que sur la primary. Ignorez ce point s'il n'y a pas de standby.
• Le cluster est sain et les instances sont ouvertes sur tous les nœuds ; les prérequis détaillés du patch RAC se trouvent dans le guide Oracle RAC 19c rolling Release Update.
• Conditions Standby-First (MOS 1265700.1) : le README de la RU indique 'Data Guard Standby-First Installable' (c'est le cas des Release Updates ; pour les one-offs, consultez leur README)… ; l'OJVM RU 19c n'est pas Standby-First sans condition (voir la note ci-dessous)… ; l'écart de patch entre primary et standby n'est maintenu que pendant la (courte) période de transition ; datapatch s'exécute une seule fois, uniquement sur la primary, une fois toutes les standbys et la primary patchées.… Toutes les standbys de cette primary ont les binaires de la nouvelle RU installés et poursuivent l'apply.…

Phases du guide

• RAC : vérifier l'environnement et passer au guide de rolling patch — Vérifier le cluster et les nœuds · Appliquer le guide de rolling patch RAC
• Contrôles préalables — Vérifier le niveau de patch actuel (home DB) · Vérifier le niveau de patch actuel (home Grid) · Vérifier l'état de la base et l'historique des patches SQL · Vérifier le rôle de la standby et l'état de l'apply (standby Data Guard) · Vérifier l'état de Data Guard (primary) · Vérifier que la nouvelle RU est installée sur les standbys …
• Sauvegarde et point de retour — Vérifier les sauvegardes RMAN · Arrêter le Redo Apply (standby Data Guard) · Créer un guaranteed restore point · Créer un guaranteed restore point (standby)
• Application : in-place (opatch apply) — Arrêter la base et le listener · Sauvegarder l'ORACLE_HOME et l'inventaire · Appliquer la RU (opatch apply) · Appliquer l'OJVM RU · Démarrer le listener et la base · Démarrer le listener et la standby en MOUNT, activer l'apply
• Application : in-place (Oracle Restart, opatchauto) — Arrêter Oracle Restart (pour la sauvegarde) · Sauvegarder le home Grid, le home DB et l'inventaire · Démarrer Oracle Restart · Appliquer la GI RU (opatchauto) · Appliquer l'OJVM RU au home DB · Démarrer le Redo Apply (standby Data Guard)
• Application : out-of-place (nouveau home) — Créer le répertoire du nouveau home · Décompresser le logiciel de base et mettre à jour OPatch · Préparer le response file du nouveau home · Installer le nouveau home avec la RU · Exécuter root.sh (nouveau home) · Comparer les patches de l'ancien et du nouveau home …
• Patch au niveau SQL (datapatch) — Exécuter datapatch · Recompiler les objets invalides (utlrp) · Ne pas exécuter datapatch sur la standby · Vérifier que les modifications SQL parviennent aux standbys
• Vérification — Vérifier le niveau de patch binaire · Vérifier le niveau de patch binaire (home Grid) · Vérifier le registre des patches SQL et les objets · Vérifier sur la standby que l'apply se poursuit avec les nouveaux binaires · Vérifier l'alert log · Effectuer les tests applicatifs …
• Clôture — Supprimer le restore point · Supprimer le restore point (standby) · Faire le ménage
• Retour arrière (uniquement si nécessaire) — Arrêter la base et le listener · Annuler les patches (opatch rollback) · Annuler les patches (opatchauto rollback) · Revenir à l'ancien home · Démarrer la standby en MOUNT avec les anciens binaires et lancer l'apply · Démarrer et annuler les patches SQL (datapatch) …