Oracle Data Guard : exploitation courante et scénarios de panne (19c / 23ai)

Runbook d'exploitation courante et de reprise après panne pour une configuration Data Guard (physical standby) existante ; pour la mise en place initiale, utilisez le guide d'installation Data Guard. Si vous ne savez pas quoi faire, commencez par 'Contrôle de l'état et du retard' : le diagnostic en lecture seule vous oriente vers le bon scénario (switchover planifié, failover, reinstate de l'ancien primary, trou d'archives, mise à niveau par RECOVER … FROM SERVICE, reconstruction du standby, snapshot standby, apply/read-only, mode de protection/FSFO/observer, opérations sur datafiles et redo logs, sauvegarde RMAN depuis le standby). Chaque scénario suit le schéma diagnostic → filet de sécurité → exécution → vérification → suites ; il donne les chemins avec broker (DGMGRL) et sans broker (SQL), avec les différences entre instance unique / Oracle Restart / RAC.

Topologie: Primary (instance unique / Oracle Restart / RAC) + physical standby (instance unique / Oracle Restart / RAC) + observer facultatif

Scénarios

• Contrôle de l'état et du retard (tout va-t-il bien ?) — Lecture seule : configuration, transport/apply lag, trou d'archives, processus et alert log ; rien n'est modifié. Si vous ne savez pas quoi faire, commencez ici : la dernière étape indique le bon scénario d'après la sortie.
• Switchover planifié (permuter les rôles) — Le primary et le standby sont sains et vous voulez permuter les rôles de façon planifiée (maintenance, exercice PRA, retour aux rôles d'origine) ; aucune perte de données, l'application est interrompue quelques minutes. Tant que vous pouvez joindre le primary, choisissez toujours ce scénario pour un changement de rôle.
• Primary perdu : failover vers le standby — Le primary est injoignable et ne reviendra pas (perte du serveur, du stockage ou du site) ; le standby devient primary. Irréversible : en MaxPerformance, les données des dernières secondes peuvent être perdues et l'ancien primary nécessite ensuite un reinstate ou une reconstruction. Si vous joignez encore le primary, choisissez le switchover.
• Après un failover, réintégrer l'ancien primary comme standby (reinstate) — Un failover a eu lieu et le serveur de l'ancien primary est revenu ; si Flashback Database est activé, il devient standby du nouveau primary sans reconstruction. Le nouveau primary reste ouvert. Si le flashback est désactivé ou si la fenêtre ne suffit pas, l'étape de diagnostic vous oriente vers une reconstruction.
• Trou d'archives (gap) : le standby attend des archive logs manquants — v$archive_gap renvoie des lignes ou l'alert log contient un message FAL/gap ; l'apply est bloqué sur une séquence. Les bases restent ouvertes. Si les archives manquantes n'existent plus nulle part, le choix du formulaire bascule vers la mise à niveau incrémentale (roll forward).
• Standby très en retard ou archives absentes : mise à niveau (RECOVER FROM SERVICE) — Les archives du gap n'existent plus nulle part, des opérations NOLOGGING ont corrompu le standby ou le standby a plusieurs jours de retard ; le standby est resynchronisé de façon incrémentale depuis le primary, sans reconstruction (18c+).
• Reconstruire le standby depuis zéro — Le reinstate (pas de flashback) et la mise à niveau incrémentale sont impossibles, ou les fichiers/le fichier de contrôle du standby sont perdus ; le standby est supprimé puis recréé par DUPLICATE. Le primary reste ouvert mais sans protection jusqu'à la fin de la reconstruction (s'il n'y a pas d'autre standby).
• Convertir en snapshot standby / revenir (copie modifiable pour tests) — Vous voulez ouvrir temporairement le standby en lecture-écriture pour des tests, puis abandonner les modifications et revenir en physical standby ; le primary n'est pas affecté, le redo continue d'être reçu, mais pendant la durée du snapshot ce standby n'est pas prêt pour un failover.
• Arrêter / démarrer le Redo Apply, changer l'instance d'apply, ouvrir en read-only — Vous voulez arrêter le MRP pour une maintenance ou le redémarrer, déplacer l'apply vers une autre instance d'un standby RAC, ou ouvrir le standby pour du reporting (avertissement de licence Active Data Guard).
• Mode de protection, Fast-Start Failover et observer — Vous voulez passer d'un mode à l'autre entre MaxPerformance / MaxAvailability / MaxProtection, activer ou désactiver le FSFO, ou gérer l'observer.
• Ajout de datafile, redo log et standby redo log / fichier UNNAMED — Un datafile ou un redo log doit être ajouté au primary, un fichier UNNAMED est apparu sur le standby (ORA-01111/ORA-01274) ou des standby redo logs manquent.
• Sauvegarder avec RMAN depuis le standby — Vous voulez exécuter la sauvegarde RMAN sur le standby pour décharger le primary et adapter la politique de suppression des archives en conséquence.

Avant de commencer

• Sur tous les serveurs, le profil de l'utilisateur oracle définit ORACLE_HOME=…, ORACLE_SID (…en RAC selon le nœud …1, …2 …………) et PATH ; sqlplus, rman…, dgmgrl… fonctionnent. La configuration a été mise en place avec le guide d'installation Data Guard ou de façon équivalente (alias TNS …, …, enregistrements statiques _DGMGRL dans le listener, même fichier de mots de passe).
• Il a été vérifié que les rôles correspondent aux saisies : actuellement … est primary et … physical standby. Sinon (p. ex. après un switchover antérieur), intervertissez les noms dans les saisies.
• Le mot de passe SYS est connu (le changement de rôle, le redémarrage de l'instance distante et RMAN FROM SERVICE exigent une connexion avec mot de passe). Le mot de passe ne contient ni @, ni /, ni ", ni espace.
• Licence : Data Guard est inclus dans Enterprise Edition. Utiliser le standby ouvert pendant que l'apply tourne, le block change tracking sur le standby et Far Sync nécessitent une licence Active Data Guard. Le snapshot standby et l'ouverture en read-only avec l'apply arrêté ne nécessitent pas de licence.
• La modification a lieu dans une fenêtre de maintenance validée ; les équipes applicatives et de supervision sont informées… (les connexions sont coupées quelques minutes)….
• La décision de failover a été prise par une personne habilitée ; il est garanti que l'ancien primary ne sera pas rouvert (split-brain) : serveur éteint, isolé du réseau ou instance maintenue en MOUNT.

Phases du guide

• État : configuration, retard et processus (lecture seule) — Afficher la configuration du broker et l'aptitude au changement de rôle · Contrôler le côté primary en SQL · Contrôler le côté standby en SQL · Rechercher les erreurs Data Guard dans les alert logs · Interpréter le résultat et choisir le bon scénario
• 1. Diagnostic : prêt pour le switchover ? — Vérifier l'aptitude (VALIDATE) · Vérifier l'aptitude (SWITCHOVER … VERIFY) · Contrôler le retard du standby
• 2. Filet de sécurité — Sauvegarder la configuration actuelle (primary) · Sauvegarder la configuration actuelle (standby)
• 3. Exécution : switchover — Switchover : … devient primary (broker) · Lancer le switchover (primary → standby) · Ouvrir le nouveau primary (…) · Mettre à jour le rôle dans Clusterware (nouveau primary) · Ouvrir l'autre instance (nouveau primary, nœud … : …) · Démarrer l'ancien primary en MOUNT comme standby (…) …
• 4. Vérification — Vérifier les nouveaux rôles et la configuration · Contrôler l'apply et le retard sur le nouveau standby
• 5. Suites — Contrôles applicatifs, des jobs et de la supervision
• 1. Diagnostic : le failover est-il vraiment nécessaire ? — Tenter une dernière fois de joindre le primary (depuis le standby) · Évaluer l'état du standby et la perte de données possible · Afficher l'état vu par le broker (depuis le standby)
• 2. Filet de sécurité et redo restant — Sauvegarder les paramètres actuels du standby · Démarrer l'ancien primary en MOUNT et envoyer le redo restant (FLUSH REDO) · Copier manuellement les archives manquantes (sans broker, si possible)
• 3. Exécution : failover — Failover : … devient primary (broker) · Arrêter le Redo Apply et effectuer le failover (SQL) · Ouvrir le nouveau primary (SQL) · Mettre à jour le rôle dans Clusterware (nouveau primary) · Ouvrir l'autre instance (nouveau primary, nœud … : …)
• 4. Vérification — Vérifier le nouveau primary
• 5. Suites — Faire une sauvegarde complète du nouveau primary · Si l'ancien primary revient : NE L'OUVREZ PAS
• Service applicatif (basé sur le rôle) — Définir et démarrer le service côté … (Clusterware) · Définir le service côté … (Clusterware) · Définir le service et le trigger de rôle (sans Grid) · Configurer la définition de connexion client avec deux adresses
• 1. Diagnostic : le reinstate est-il possible ? — Contrôler le nouveau primary et le SCN du changement de rôle · Afficher l'état du broker (nouveau primary) · Démarrer l'ancien primary en MOUNT et contrôler la fenêtre de flashback
• 2. Filet de sécurité — Sauvegarder le fichier de contrôle et les paramètres de l'ancien primary
• 3. Exécution : reinstate — Réintégrer l'ancien primary (reinstate, broker) · Démarrer les autres instances (ancien primary, RAC) · Revenir en arrière par flashback et convertir en physical standby (SQL) · Activer la destination … sur le nouveau primary (SQL) · Démarrer le Redo Apply et passer les enregistrements de changement de rôle (SQL)
• 4. Vérification — Vérifier la configuration · Vérifier l'apply sur l'ancien primary (nouveau standby)
• 5. Suites — Rétablir les rôles d'origine (facultatif) et traiter la cause racine
• 1. Diagnostic : où est le trou, les archives existent-elles ? — Afficher le trou et les processus sur le standby · Contrôler la connexion FAL et l'alert log (standby) · Les archives manquantes sont-elles sur le primary ? · Les archives manquantes sont-elles dans une sauvegarde RMAN ?
• 2. Filet de sécurité — Vérifier qu'il reste de la place dans la FRA du standby
• 3. Exécution : récupérer et enregistrer les archives manquantes — Si les archives ne sont que dans une sauvegarde : les restaurer sur le primary · Copier les archives manquantes sur le système de fichiers et les envoyer au standby (primary) · Enregistrer les archives sur le standby · Redémarrer le Redo Apply (standby)
• 4. Vérification — Surveiller la fermeture du trou (standby)
• 5. Suites — Supprimer les copies temporaires · Traiter la cause racine
• 1. Diagnostic : quel est le retard du standby ? — Afficher le SCN et l'état du standby · Contrôler les opérations NOLOGGING et la valeur de COMPATIBLE sur le primary
• 2. Filet de sécurité — Sauvegarder le fichier de contrôle et le spfile du standby
• 3. Exécution : mettre le standby à niveau — Arrêter le Redo Apply (standby) · Passer le standby en MOUNT… (1re instance seulement)… · Mettre le standby à niveau depuis le primary (RECOVER STANDBY DATABASE FROM SERVICE) · Démarrer les autres instances du standby · Contrôler l'état des standby redo logs et du flashback · Démarrer le Redo Apply (standby)
• 4. Vérification — Vérifier que le retard est résorbé
• 5. Suites — Traiter la cause racine
• 1. Diagnostic : la reconstruction est-elle vraiment nécessaire ? — Afficher l'état de la configuration et du primary
• 2. Filet de sécurité — Conserver les fichiers de configuration du standby
• 3. Exécution : supprimer et reconstruire — Retirer le standby de la configuration du broker · Suspendre la destination standby sur le primary (DEFER) · Supprimer l'ancienne base standby · Nettoyer les fichiers broker, init et de mots de passe restants · Mettre de côté l'ancien fichier init (standby, nœud … : …) · Recréer le standby avec le guide d'installation …