Restauration et récupération avec RMAN

Guide pas à pas pour exécuter la bonne récupération RMAN au moment de la panne : 19 scénarios — perte de datafile, de SYSTEM/UNDO, de tempfile, blocs corrompus, perte de online redo log, de controlfile ou de spfile ; restauration complète, restauration vers un autre répertoire/vers ASM et sur un autre serveur ; retour à un point dans le temps (PITR de la CDB ou de la PDB), Flashback Database, PITR de tablespace, récupération d'une seule table (RECOVER TABLE), PDB supprimée ; restauration par le réseau via Data Guard (FROM SERVICE), restauration des seuls archive logs, déclaration de sauvegardes déplacées (CATALOG) et répétition sans écriture de données (PREVIEW/VALIDATE). Chaque scénario suit l'ordre diagnostic → filet de sécurité → exécution → vérification → nouvelle sauvegarde ; les étapes sont distinctes pour l'instance unique, Oracle Restart et RAC (récupération sur une seule instance avec CLUSTER_DATABASE=FALSE). Ce guide traite du retour arrière, pas de la prise de sauvegarde ; pour le plan de sauvegarde, voir le guide "Stratégie de sauvegarde Oracle".

Topologie: 1 serveur (instance unique ou Oracle Restart) ou RAC ; pour le scénario nouvel hôte, source + cible

Scénarios

• Répétition : RESTORE … PREVIEW / VALIDATE (ne modifie rien) — Rien n'est cassé ; vous voulez vérifier, sans écrire de données, que les sauvegardes suffisent réellement à un retour arrière (la base reste ouverte). C'est aussi la première étape de l'exercice de restauration mensuel et lorsque vous ne savez pas quel scénario choisir.
• Sauvegardes déplacées dans un autre répertoire / RMAN ne trouve pas la sauvegarde (CATALOG) — Les pièces de sauvegarde existent mais RMAN ne les connaît pas (déplacées, NFS modifié, copiées depuis un autre serveur) : vous obtenez RMAN-06023/06025. La base reste ouverte.
• Restaurer uniquement les archive logs (RESTORE ARCHIVELOG) — Les archives d'une plage de séquences donnée sont nécessaires sur disque pour LogMiner, un gap de standby ou une recovery manuelle ; la base reste ouverte, aucun fichier n'est écrasé.
• Perte/corruption de datafile ou de tablespace (la base reste ouverte) — La base est ouverte, seul un datafile ou un tablespace est illisible (ORA-01157/01110/01116) ; tout le reste fonctionne. Si le fichier appartient à SYSTEM/UNDO, choisissez la carte "SYSTEM ou UNDO" ; si c'est un tempfile, la carte "Tempfile" ; si le fichier s'ouvre mais que quelques blocs sont corrompus (ORA-01578), la carte "Bloc corrompu".
• Blocs corrompus (ORA-01578, block media recovery) — Une requête renvoie ORA-01578/ORA-26040, la sauvegarde s'arrête sur ORA-19566 ou VALIDATE a trouvé des blocs corrompus ; le reste du fichier est sain. La base reste ouverte, seuls les blocs corrompus sont réparés (Enterprise Edition ; en SE2, le fichier est restauré). Si le fichier entier ne s'ouvre pas (ORA-01157), carte "Un seul datafile".
• Datafile SYSTEM ou UNDO perdu (la base ne s'ouvre pas) — Le fichier perdu ou corrompu appartient au tablespace SYSTEM ou UNDO : il ne peut pas être mis offline, la base (ou seulement la PDB s'il s'agit de fichiers de PDB) est arrêtée et le fichier est restauré en MOUNT. Aucune perte de données. Si le fichier appartient à un autre tablespace, la carte "Un seul datafile" règle le problème sans arrêter la base.
• Tempfile perdu ou corrompu (tablespace TEMP) — Les tris/hash renvoient ORA-01157/ORA-01187/ORA-25153 et le fichier est un tempfile (le numéro dans le message d'erreur est supérieur à la valeur de db_files, p. ex. data file 201). Aucune restauration n'est nécessaire ; un nouveau tempfile est ajouté, la base reste ouverte.
• Online redo log perdu ou corrompu — ORA-00313/00312 (ouverture impossible) ou ORA-00327/00366/00367 (corrompu) dans l'alert log. Si un membre est perdu ou si le groupe est INACTIVE, la base reste ouverte ; si le groupe CURRENT est perdu, il faut une restauration + RESETLOGS et les dernières transactions sont perdues. L'étape de diagnostic montre l'état du groupe ; choisissez en conséquence.
• Toutes les copies du controlfile sont perdues — En phase MOUNT, l'instance ne trouve pas ou ne peut pas lire le controlfile (ORA-00205/00202/00210) ; datafiles et redo sont sains. Si l'une des copies est saine, aucune restauration n'est nécessaire (l'étape de diagnostic le montre) ; si toutes sont perdues, il est restauré depuis l'autobackup et la base est ouverte avec RESETLOGS ; les online redo étant sains, il n'y a pas de perte de données.
• spfile perdu — Le spfile a été supprimé ou corrompu ; l'instance ne démarre pas (ORA-01078/LRM-00109), ou bien l'instance tourne mais le fichier n'existe plus. Les datafiles ne sont pas touchés, aucune perte de données ; si l'instance tourne encore, il n'y a pas non plus d'interruption.
• Restauration complète, même serveur (datafiles perdus ; controlfile et redo sains) — Tous les datafiles ou la plupart ont disparu, le controlfile et les online redo logs sont sains ; la base est arrêtée, aucune perte de données. Si l'ancien disque/répertoire des fichiers n'est plus utilisable, choisissez la carte "autre répertoire" ; si le controlfile est aussi perdu, d'abord la carte "controlfile" ; si le serveur a complètement disparu, la carte "Restauration sur un autre serveur".
• Disque perdu : restaurer la base dans un autre répertoire / dans ASM (SET NEWNAME) — Le disque ou le disk group qui contient les datafiles est inutilisable ; controlfile et redo sont sains. Les fichiers sont restaurés dans un nouveau répertoire ou un disk group ASM, la base est arrêtée, aucune perte de données.
• Retour à une date / un SCN (PITR, RESETLOGS) — DELETE/UPDATE/TRUNCATE erroné ou version applicative défectueuse : ramène la base (ou seulement la PDB) à un instant passé ; toutes les modifications postérieures sont perdues (RESETLOGS). Envisagez d'abord des voies plus ciblées : une seule table → "Récupérer une seule table", un seul tablespace → TSPITR, flashback activé → "Flashback Database" (aucune restauration, beaucoup plus rapide).
• Rembobiner avec Flashback Database (restore point / SCN / heure) — Flashback est activé ou un guaranteed restore point existe, et aucun fichier n'est perdu : la base est rembobinée en quelques minutes sans restauration (Enterprise Edition). RESETLOGS est requis. Pour vérifier l'activation : SELECT flashback_on FROM v$database; → YES, ou une ligne GUARANTEE_FLASHBACK_DATABASE = YES dans v$restore_point.
• Ramener un tablespace à un point dans le passé (TSPITR) — L'opération erronée ne concerne que des objets situés dans un seul tablespace ; le reste de la base doit rester dans le présent (Enterprise Edition). Le tablespace est offline pendant toute l'opération et tous ses objets reviennent au point cible ; si seules une ou deux tables sont touchées, "Récupérer une seule table" ramène moins de choses en arrière.
• Récupérer une seule table (RECOVER TABLE, 12c+ Enterprise Edition) — Une seule table a été supprimée ou endommagée par erreur ; le reste de la base doit rester tel quel (12c+ Enterprise Edition). Si la table a été supprimée par DROP sans PURGE, regardez d'abord la recyclebin : FLASHBACK TABLE … TO BEFORE DROP prend quelques secondes (l'étape de diagnostic le montre).
• Récupérer une PDB supprimée (DROP PLUGGABLE DATABASE) — Une PDB a été supprimée avec DROP PLUGGABLE DATABASE. Si les fichiers sont toujours là, la PDB est rebranchée avec le XML ; s'ils ont été supprimés, la PDB est récupérée depuis la sauvegarde (21c+ en une seule commande, 19c via une CDB temporaire). La CDB reste ouverte.
• Restauration sur un autre serveur (nouvel hôte, depuis l'autobackup du controlfile) — Le serveur est entièrement perdu, ou un environnement de copie/test doit être monté : la sauvegarde est restaurée sur un autre serveur (instance unique sur système de fichiers seulement). La récupération va jusqu'au dernier archive log sauvegardé, la suite est perdue ; la copie est ouverte avec RESETLOGS.
• Data Guard : récupérer le fichier depuis la standby/primaire par le réseau (FROM SERVICE) — Data Guard est en place : vous récupérez un datafile perdu sur la primaire depuis la standby, et une standby en retard ou un controlfile de standby perdu depuis la primaire, sans utiliser de pièces de sauvegarde (12c+).

Avant de commencer

• L'incident a été consigné et l'équipe applicative informée : quand, quoi, quel message d'erreur. Si une copie de l'état actuel peut être prise avant le début de la récupération, cette copie a été prise (snapshot serveur/disque, ou au minimum une copie des datafiles restants, du controlfile et des online redo logs) ; une mauvaise manipulation peut aggraver la situation.
• Les sauvegardes sont accessibles : …… et, pour les archive logs, la FRA …… sont montés et lisibles. Si les sauvegardes sont sur bande/MML, le canal SBT et l'agent logiciel fonctionnent.
• Le DBID est connu (…). Sinon : la ligne connected to target database: … (DBID=…) des anciens logs RMAN… ou le nom du fichier d'autobackup (…_cf_c-<DBID>-<YYYYMMDD>-<nn>)….
• Le répertoire auxiliary … existe et dispose d'autant d'espace libre que SYSTEM + SYSAUX + UNDO + le tablespace de la table ; le serveur a ~2 Go de RAM libre pour l'instance temporaire.
• …RECOVER TABLE ("Recovering tables and table partitions from RMAN backups") est une fonctionnalité Enterprise Edition.…Standard Edition 2 ne dispose pas de RECOVER TABLE : au lieu des étapes ci-dessous, restaurez la sauvegarde sur un autre serveur ("Restauration sur un autre serveur" + PITR) et extrayez la table avec Data Pump.…
• La même version d'Oracle et le même niveau de RU sont installés en logiciel seul sur le serveur cible (opatch lspatches identique des deux côtés), l'utilisateur/les groupes oracle et l'arborescence des répertoires sont identiques à la source, l'espace disque est suffisant. Aucune base du même nom ne tourne sur la cible.
• La fenêtre de maintenance/d'interruption a été validée… (dans ce scénario, la base reste ouverte ; seuls les objets concernés sont touchés)…. Le planificateur des sauvegardes (cron/systemd/scheduler) est arrêté jusqu'à la fin de la récupération ; sinon une sauvegarde ou un DELETE OBSOLETE pourrait se lancer au milieu de l'opération.
• L'enregistrement dans Clusterware est connu : emplacement du spfile et du fichier de mots de passe, …instances et nœuds…état de la base… (srvctl config database -db …). Conservez cette sortie avant la récupération.
• …Block media recovery…Tablespace point-in-time recovery…Flashback Database… est une fonctionnalité Enterprise Edition ; la commande ne fonctionne pas en Standard Edition 2. Le chemin SE2 de ce scénario est indiqué séparément dans les étapes.
• Pour l'instance temporaire (auxiliary), le répertoire …………… dispose d'autant d'espace libre que SYSTEM + SYSAUX + UNDO… + …… + PDB…, et le serveur a au moins autant de mémoire libre que le sga_target de la cible (par défaut, RMAN donne la même SGA à l'instance temporaire).
• Data Guard est prêt : le fichier de mots de passe est identique des deux côtés (même mot de passe SYS ou SYSBACKUP), le tnsnames.ora de ce serveur contient les entrées … et …, COMPATIBLE ≥ 12.0. FROM SERVICE ne fonctionne pas avec l'authentification du système d'exploitation (rman target /) ; RMAN se connecte avec un mot de passe.
• Pour Flashback Database, une FRA est définie et, au choix, le flashback logging est activé (FLASHBACK_ON = YES) ou le point cible est un guaranteed restore point. Aucun datafile n'est perdu/corrompu (le flashback ne ramène pas un fichier perdu) et, depuis le point cible, aucun shrink de datafile ni aucune recréation du controlfile n'est intervenu.

Phases du guide

• État des lieux — Faire l'état des lieux · Faire l'état des lieux · Vérifier la recyclebin (après un DROP, aucune sauvegarde ne sera peut-être nécessaire) · Déterminer le point cible
• Sauvegarde nécessaire disponible ? — Démarrer l'instance en mode MOUNT · Démarrer l'instance en mode MOUNT (srvctl) · Lister les sauvegardes · Trouver les fichiers d'autobackup · Prévisualiser la récupération (PREVIEW) · Lire et valider les pièces de sauvegarde (VALIDATE) …
• Récupération de datafile / tablespace (en ligne) — Mettre … offline · Restaurer et récupérer … · Mettre … online
• Restauration complète (même serveur) — Restaurer, récupérer et ouvrir la base · …Revenir en mode cluster et démarrer la base avec Clusterware…Redémarrer la base avec Clusterware (Oracle Restart)…
• Retour à une date / un SCN (PITR) — Sauvegarder l'état actuel avant le retour arrière · Passer la base en MOUNT sur une seule instance (srvctl) · Ramener …la PDB…la base… au point cible · …Revenir en mode cluster et démarrer la base avec Clusterware…Redémarrer la base avec Clusterware (Oracle Restart)…
• Récupérer une seule table (RECOVER TABLE) — Préparer le répertoire auxiliary · Récupérer la table au point cible · Comparer les données récupérées
• Restauration du controlfile — Vérifier s'il reste une copie du controlfile · Vérifier s'il reste une copie du controlfile (ASM) · Démarrer l'instance en NOMOUNT (srvctl) · Restaurer le controlfile depuis l'autobackup et ouvrir la base · …Revenir en mode cluster et démarrer la base avec Clusterware…Redémarrer la base avec Clusterware (Oracle Restart)…
• Restauration du spfile — Réécrire le spfile à partir des paramètres en mémoire · Écrire le spfile dans ASM à partir des paramètres en mémoire · Restaurer le spfile depuis l'autobackup · Restaurer le spfile depuis l'autobackup dans ASM · Vérifier que l'instance a démarré avec le spfile
• Serveur source : collecter les informations et transférer les sauvegardes — Prendre une sauvegarde à jour · Écrire le DBID, l'autobackup et les répertoires · Copier les sauvegardes et le fichier de mots de passe vers la cible
• Serveur cible : restauration et récupération — Créer les répertoires · Ajouter l'entrée oratab · Restaurer le spfile et le controlfile, monter la base · Déclarer les pièces de sauvegarde (CATALOG) · Restaurer, récupérer jusqu'à la dernière archive et ouvrir la base · Détacher la copie de la source (facultatif)
• Diagnostic : pourquoi RMAN ne trouve-t-il pas la sauvegarde ? — Voir le nouvel emplacement des pièces de sauvegarde · Lister les sauvegardes connues de RMAN et celles qui manquent
• Filet de sécurité — Copier l'état actuel du controlfile
• Déclarer les sauvegardes à RMAN — Déclarer les pièces du nouveau répertoire (CATALOG START WITH) · Nettoyer les enregistrements de l'ancien emplacement
• Vérification : les sauvegardes sont-elles maintenant trouvées ? — Prévisualiser à nouveau la récupération · Adapter le script de sauvegarde au nouvel emplacement
• Diagnostic : quelles archives sont nécessaires et figurent-elles dans la sauvegarde ? — Vérifier si les archives sont sur disque · Trouver la sauvegarde des archives et prévisualiser
• Filet de sécurité : répertoire cible et espace — Préparer le répertoire de restauration
• Restaurer les archives — Restaurer les archives (RESTORE ARCHIVELOG)
• Vérification et nettoyage — Lister les archives restaurées · Supprimer les archives restaurées une fois le travail terminé
• Diagnostic : s'agit-il de blocs corrompus ? — Analyser le fichier (VALIDATE) · Lister les blocs corrompus et les objets auxquels ils appartiennent
• Filet de sécurité : existe-t-il une copie intacte et une chaîne d'archives ? — Prévisualiser les sauvegardes du fichier et la chaîne de récupération
• Réparer les blocs corrompus — Réparer les blocs corrompus depuis la sauvegarde (RECOVER CORRUPTION LIST) · Standard Edition 2 : restaurer le datafile · Corriger les blocs NOLOGGING (le cas échéant)
• Vérification : les blocs sont-ils intacts ? — Analyser à nouveau le fichier · Rechercher la cause première : erreurs disque et stockage
• Diagnostic : le fichier est-il SYSTEM ou UNDO ? — Démarrer l'instance en mode MOUNT · Démarrer l'instance en mode MOUNT (srvctl) · Vérifier que le fichier est SYSTEM ou UNDO · Prévisualiser et valider la sauvegarde nécessaire
• Filet de sécurité — Copier l'état actuel du controlfile
• Restaurer le datafile SYSTEM / UNDO — Fermer la PDB · Restaurer, récupérer et ouvrir le datafile · …Revenir en mode cluster et démarrer la base avec Clusterware…Redémarrer la base avec Clusterware (Oracle Restart)…
• Diagnostic : le fichier perdu est-il un tempfile ? — Voir les tempfiles et leur état · Vérifier le fichier et l'alert log
• Filet de sécurité : contrôle de l'espace — Vérifier qu'il y a de la place pour le nouveau tempfile
• Ajouter un nouveau tempfile, retirer celui qui est perdu — Ajouter un nouveau tempfile et retirer celui qui est perdu
• Vérification — Vérifier le tablespace temporaire
• Diagnostic : quel groupe, dans quel état ? — Voir l'état des groupes de redo log