RESTAURATION D'UNE DB ORACLE (2ème PARTIE)

III - Restauration-récupération incomplète basée sur le temps d'une base Oracle à l'aide de RMAN
Plusieurs possibilités s'offrent à l'administrateur. Avant de les analyser, listons les. Il s'agit de :
- Restauration-récupération incomplète avec utilisation d'un fichier de contrôle provenant d'une sauvegarde (scénario 1) ;
- Restauration-récupération incomplète après désactivation de quelques jeux de sauvegarde (scénario 2) ;
- Restauration-récupération incomplète avec choix explicite du jeu de sauvegarde à utiliser (scénario 3) ;
- Restauration-récupération incomplète avec choix implicite du jeu de sauvegarde à utiliser (scénario 4) ;
Afin de rendre les explications qui vont suivre plus intelligibles, appuyons-nous sur un cas concret que nous avons rencontré en production.
Notre base de données (appelons-le pagenet) est sauvegardée (sauvegarde complète) tous les jours à 22h00. Le jeudi 16 février 2006 à 17h45, suite à un incident qu'un administrateur junior (donc non expérimenté) jugeait mineur, il refait une sauvegarde totale de la base. De l'analyse approfondie de l'incident, il ressort qu'il est dû à un chargement massif de données erronées dans la base de données.

Conclusion : il est urgent de restaurer la base de données en évitant d'utiliser la dernière sauvegarde totale faite par l'administrateur junior ou plus précisément en utilisant la sauvegarde totale faite le 16 février 2006 à 11heures00 après des travaux de maintenance. Toutes les sauvegardes totales comportent toujours une sauvegarde du fichier de contrôle et une sauvegarde du fichier d'initialisation SPFILE. L'identifiant de la base de données est DBID=2093727724.

Les développements qui suivent s'appuyent sur un exemple que le lecteur/internaute trouvera dans la 3ème partie intitulée "ANNEXE - EXEMPLE DE TRAVAIL".

III – 1) Scénario 1
Nous supposons que le jeu de sauvegarde (backupset) qui inclut le fichier de contrôle est le 1383. On peut trouver le nom du fichier correspondant à ce jeu de sauvegarde à l'aide de la commande RMAN list comme suit :
RMAN> list backupset 1383;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1383 Full 18M DISK 00:00:01 16/02/06
BP Key: 1356 Status: AVAILABLE Tag:
Piece Name: /sauvebd/PAGENET/backup_ctl_c-2093727724-20060216-00
Controlfile Included: Ckp SCN: 308507599 Ckp time: 16/02/06
RMAN>

Après avoir arrêté la base de données, se connecter à la base et exécuter la séquence qui suit :
$ rman
RMAN> connect target /
RMAN> startup nomount ;
RMAN> set dbid 2093727724 ;
RMAN> run { restore controlfile from '/sauvebd/PAGENET/backup_ctl_c-2093727724-20060216-00' ;
alter database mount ;
set until time "to_date('16/02/2006 17:43:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database ;
recover database ;
}
RMAN> alter database open resetlogs ;


III – 2) Scénario 2
Nous faisons l'hypothèse que l'administrateur ne souhaite pas procéder à la restauration à partir des jeux de sauvegarde de la sauvegarde la plus récente (la plus optimale du point de vue de RMAN). En ce qui concerne notre exemple de travail (voir en annexe), l'administrateur ne souhaite pas utiliser les jeux de sauvegarde dont les numéros vont de 1384 à 1392. Il va donc les désactiver en leur affectant le status "UNAVAILABLE (U) à l'aide de la commande RMAN "change backupset unavailable ;". La séquence de commandes donne ce qui suit :
$ rman
RMAN> connect target /
RMAN> startup mount ;
RMAN> change backupset 1384, 1385, 1386, 1387, 1388, 1389, 1390, 1391, 1392 unavailable ;
RMAN> run { set until time "to_date('16/02/2006 17:43:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database ;
recover database ;
}
RMAN> alter database open resetlogs ;
Une fois la restauration effectuée, l'administrateur peut toujours réactiver les jeux de sauvegarde précédemment désactivés en tapant la commande suivante :
RMAN> change backupset 1384, 1385, 1386, 1387, 1388, 1389, 1390, 1391, 1392 available ;

III – 3) Scénario 3
En analysant bien notre exemple en annexe, le lecteur se rendra compte que tous les jeux de sauvegarde de datafiles d'une même sauvegarde ont le même tag ou étiquette. Le scénario 3 s'appuyera sur cette étiquette pour demande la restauration à partir d'une sauvegarde bien précise. Dans le cadre de notre exemple l'étiquette est TAG20060215T220244. Il en résulte la séquence qui suit :
$ rman
RMAN> connect target /
RMAN> startup mount ;
RMAN> run { set until time "to_date('16/02/2006 17:43:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database from tag 'TAG20060215T220244' ;
recover database ;
}
RMAN> alter database open resetlogs ;

III – 4) Scénario 4
Il arrive parfois des situations dans lesquelles on peut aboutir au résultat escompté, rien qu'en jouant sur les dates au sens large du terme c'est-à-dire dates et heures. Appliquons ce scénario à notre contexte. Rappelons ledit contexte : une sauvegarde totale a eu lieu le 15/02/2006 à 22heures ; une autre a eu lieu le 16/02/2006 à 11heures et enfin la dernière a eu lieu le 16/02/2006 à 17h45.
Il est à noter que lorsque plusieurs sauvegardes totales sont faites dans la même journée, le champ "Completion time" du résultant de la commande RMAN "list" ne permet pas de les distinguer. Or il est capital de connaître les heures afin de s'assurer que l'on a bien choisi la bonne sauvegarde. Pour cela il vaut mieux interroger l'une des deux vues v$backup_piece ou v$backup_set. Voici deux exemples d'interrogations de ces vues
SQL> select recid, piece#, handle, to_char(completion_time, 'DD/MM/YYYY HH24:MI:SS') moment

SQL> from v$backup_piece where status = 'A'
SQL> and to_char(completion_time, 'DD/MM/YYYY') = '16/02/2006' ;

SQL> select recid, pieces, to_char(completion_time, 'DD/MM/YYYY HH24:MI:SS') moment,

SQL> backup_type
SQL> from v$backup_set

SQL> where to_char(completion_time, 'DD/MM/YYYY') = '16/02/2006' ;

Pour atteindre notre but il suffit de demande une restauration-récupération incomplète jusqu'à une minute avant la sauvegarde totale qui comporte les mauvaises données c'est-à-dire 17h44. Dans la mesure où la dernière sauvegarde totale (la mauvaise) n'existait pas le 16/02/2006 à 17:44, RMAN évitera automatiquement d'utiliser cette sauvegarde et utilisera celle qui l'a précédée. D’où la séquence de commandes RMAN suivante :
$ rman
RMAN> connect target /
RMAN> startup mount ;
RMAN> run { set until time "to_date('16/02/2006 17:44:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database ;
recover database ;
}
RMAN> alter database open resetlogs ;

Il est important de noter aussi que la place de la commande set until time "to_date('16/02/2006 17:44:00', 'DD/MM/YYYY HH24:MI:SS')"; est cruciale dans la séquence. Si cette commande était placée après la commande "restore database ; ", on aurait eu un superbe message d'erreur. En effet, n'ayant pas de "until time" pour la commande restore, RMAN aurait sélectionné la sauvegarde de 17h45 (l'optimale), mais quand il va aborder la commande "recover database ;", RMAN va se rendre compte qu'on lui demande l'impossible ou plus exactement, qu'on lui demande une récupération pas en cohérence avec la restauration qu'elle vient de faire. D'où le message d'erreur.

A SUIVRE ...