RMAN : Restauration

Ce chapitre traite des opération de restauration et de recovery des bases Oracle à l’aide de RecoveryManager, cependant, nous ne traiterons ici que de la restauration des databases en mode ARCHIVELOG, le mode NOARCHIVELOG ne nécessitant aucune difficulté particulière pour des procédures de sauvegardes / restaurations et se résumant à de la simple sauvegarde de fichiers du point de vue de l’OS.

Nous postulons donc dans ce chapitre que toutes les bases sotn en mode ARCHIVELOG et qu’elles disposent égallement de zones de restauration rapides (FlashBack).

1) Introduction :

La commande qui permet à RMAN d’éffectuer une restauration de tout ou partie d’une base de données est RESTORE.

Dans certains cas, il sera nécessaire de demander à RMAN de pratiquer un recovery après une restauration de données afin de rendre la database cohérente grâce aux archivelogs au préalablement sauvegardés.La commande qui permet à RMAN d’éffectuer un recovery après est RECOVER (le terme francisé “officiel” Oracle est ”RECUPERATION”)

Chaque opération de restauration peut amener des situation particulières, il faut donc, avant toute restauration, faire le point sur la situation afin de déterminer quelles sont les actions à mener et de ne pas se précipiter.

1.1) Restauration de données :

La restauration de données s’éffectue avec la commande RMAN RESTORE et permet de faire référence à un certain nombre d’objets (base de données, fichier de données, fichier de contrôle, fichier de paramètre, …).

Syntaxe : (le nombre d’options et de commutateur n’est pas exhaustif)

RESTORE
       [ DATABASE
       | DATAFILE    <liste_des_datafiles_par_nom_ou_#>
       | TABLESPACE  <liste_des_tablespaces>
       | CONTROLFILE [ to '<dest>' ] [ from [ autobackup | '<source>] ]
       | SPFILE      [ to '<dest>' ] [ from [ autobackup | '<source>] ]
       | ARCHIVELOG  [ ALL | [ FROM TIME '<date>' | UNTILE TIME '<date>'
                           | TIME BETWEEN '<d1>' AND '<d2>] ]
       ]
       [ PREVIEW [ SUMMARY ] ]
       [ VALIDATE [ BACKUP-SET ] ]
       ...
       (consulter la doc pour les autres commutateurs)

Info: L’option PREVIEW permet de lister les éléments dont RMAN va avoir besoin pour éffectuer l’ordre de restauration, cette commande peut s’avérer utile si vous disposez d’un outil de sauvegarde désynchronisé de RMAN (par exemple utilisation de RMAN pour sauvegarder vers du disque et déport du disque vers LTO avec un logiciel de sauvegarde de fichiers (TINA, TSM, …)). L’option PREVIEW peut être accompagnée de SUMMARY qui donnera un affichage détaillé de cette commande.

Info: L’option VALIDATE permet de tester si l’opération de restauration peut être exécutée sans erreur (vérification de l’existence et de la consistence de tous les fichiers nécéssaires à cette restauration avant restauration).

1.2) Récupération de données (“recovery”) :

La syntaxe de la commande RECOVER est la suivante :

RECOVER
       [ DATABASE
       | DATAFILE    <liste_des_datafiles_par_nom_ou_#>
       | TABLESPACE  <liste_des_tablespaces>
       ]
       [ DELETE ARCHIVELOG  [ MAXSIZE <size> [K|M|G] ] ]
       ...
       (consulter la doc pour les autres commutateurs)

Note: Les fichiers de journalisations archivés manquant et restaurés par RMAN le seront dans le répertoire de l’instance prévu à cet effet dans LOG_ARCHIVE_DEST_1. L’option “DELETE ARCHIVELOG” permet de supprimer les fichier de journalisés archivés restaurés au fure et à mesure que le recovery avance et en fonction d’une taille maximum d’occupation (MAXSIZE).

2) Restauration de données :

Cet article va présenter quelques cas de restauration et de recovery isolés, mais, dans une production, vous serez probablement confronté à des cas de restauration plus complexes car mettant en cause plusieurs points simultanément.

Note: Nous considérons ici, comme toujours dans une production sérieuse, que les base de données sont en mode archivage des fichiers de journalisation (ARCHIVELOG).

RMAN prévoyant l’inclusion systématique des fichiers de contrôle et des fichiers de paramètres d’instance, nous considérerons que ceux-ci sont toujours disponibles dans les sauvegardes restaurées : en effet, horsmis pour traiter quelque cas d’école, il est strictement inintéréssant de ne pas utiliser les fonctions de sauvegardes automatique de ces fichiers.

2.1) Restauration d’un fichier de paramètre serveur (SPFILE) :

La présence du SPFILE est la première chose dont à besoin l’instance Oracle pour démarrer, il est donc strictement indispensable d’en détenir des copies de sauvegarde. Vous pouvez même automatiser une simple copie régulière de ce fichier (en dehors de l’autobackup de RMAN) car celui-ci ne pèse vraiment pas lourd et se passer de lui peut poser problème.

Il est aisé de recréer le SPFILE à partir d’un simple fichier texte que vous aurez au préalablement sauvegardé, c’est aussi la méthode la plus rapide en dehors d’une sauvegarde par RMAN, il est dommage de s’en priver.

La méthode de restauration d’un SPFILE par RMAN est simple, un petit exemple se passe de commentaires :

1 : RMAN> set dbid 5687165146;

2 : RMAN> startup nomount;
échec du démarrage : ORA-01078 : failure in processing system parameters ...

3 : RMAN> restore spfile from autobackup;

4 : RMAN> shutdown;

5 : RMAN> startup;

Cette méthode permet de restaurer aisément un fichier de préférence serveur qui aurait été sauvegardé en mode automatique par RMAN (autobackup). Si vous désirez spécifier un chemin exact pour pointer une sauvegarde RMAN d’un SPFILE, il vous suffit de remplacer la ligne 3 par l’emplacement tel que :

3 : RMAN> restore spfile from '/datas/sauvegardes/mabase/spfile/01_mf_s_5687165146_.bck';

Les procédures de restauration des SPFILE doivent évidement se faire en mode NOMOUNT, une erreur sera alors détectée par RMAN après l’étape [2:] car le mode NOMOUNT (mode de démarrage minimal d’une instance) exige la présence et la lecture d’un fichier de préférence, hors c’est bien celui-ci que nous avons perdu. RMAN va alors dynamiquement mettre à disposition de l’instance un PFILE minimal permettant de la démarrer et de démarrer en mode NOMOUNT afin de procéder à la restauration du SPFILE sauvegardé.

2.2) restauration des fichiers de contrôles :

La restauration d’un fichier de contrôle doit se faire UNIQUEMENT si vous avez perdu toutes les occurences de votre fichier de contrôle car, inutile de vous le rapeller, un bon DBA multiplexe ses fichiers de contrôles sur des volumes séparés (sauf baie SAN) et sur des filesystem différents, ce qui minimise largement ce risque de perte.

a – Restauration à partir d’un fichier OS intact :

Le fichier d’alerte de l’instance doit normalement vous renseigner sur l’ensemble des fichiers de contrôles perdus et donc à remplacer à partir de copie d’un des fichiers de contrôle intact. Il ne vous reste plus qu’à remplacer les copies endommagées par des instances du fichier intact (copies OS), c’est tout.

b – Restauration à partir de RMAN :

Si RMAN est à l’origine de la sauvegarde de vos fichiers de contrôles, et que vous avez activé la sauvegarde automatique (AUTOBACKUP) comme nous vous l’avons conseillé, la méthode est simple, choisissez un chemin de destination <DEST> valide pour la restauration du fichier puis modifiez le fichier de paramètre pour qu’il le prenne en compre.

Exemple:

RMAN> restore control file to '/data/tmp/ctl.bck' from autobackup;

RMAN> sql "alter system set control_files='/data/databases/base1/ctl/1.ctl',
                                         '/data/tmp/ctl.bck' scope=SPFILE;
         ";
RMAN> shutdown;
RMAN> startup;

2.3) Restauration d’un fichier de journalisation :

La perte d’un fichier de journalisation n’est pas un drame en soit pour le peu que vous ayez correctement calibré votre instance de production, à savoir que vous ayez créé plusieurs MEMBRES par GROUPE de redologs et qu’il vous reste au moins un fichier dans chaque groupe : le multiplexage des journaux est indispensable pour garantir la stabilité de la base de données.

La méthode consiste à consulter dans le fichier d’alerte quel est le fichier redolog qui pose problème afin de le détruire en l’enlevant du référentiel de l’instance et de le re-créer.

Exemple: Ici, on suppose que le fichier d’alerte montre que le fichier g2m1.log du group 2 est invalide

SQL> alter database drop logfile member '/data/base/redos/g2m1.log';

SQL> alter database add logfile member '/data/base/redos/g2m1.log' to group 2;

Remarque: La vue v$logfile donne le status des fichiers redo (valid / invalid) en cas de problème d’accès sur l’un d’eux.

Remarque: même s’il est défecteux, il est interdit de supprimer le redolog courant, vous devrez forcer Oracle à passer au groupe suivant avec ALTER SYSTEM SWITCH LOGFILE avant de faire cette opération.

2.4) Restauration complète d’une base de données :

Dans le cas où vous avez perdu tous les fichiers de données, c’est sans doute l’opération la plus simple à réaliser, en voici la syntaxe et la procédure :

RMAN> startup mount;

RMAN> restore database;

RMAN> recover database;

RMAN> sql "alter database open";

2.5) Restauration partielle d’une base de données :

Dans certains cas (rares) vous serez amenés en tant que DBA à restaurer les données à une date/heure T, selon les exigences de votre hierarchie (en dehors des pertes de données occasionnées, le client est Roi…)

Dans ce cas, vous devrez utiliser le commutateur “until time” de Rman, comme indiqué dans cet exemple ci dessous:

run {
   set until time "to_date('2011-03-01:13:00:00', 'yyyy-dd-mm:hh24:mi:ss')";
   restore database;
   recover database;
}