• Aucun résultat trouvé

Scénarios de restauration

Dans le document Administration d'une base de données (Page 32-37)

5. Sauvegarde, restauration et récupération

5.12. Restauration

5.12.6. Scénarios de restauration

2. Restauration d'un fichier de contrôle 3. Restauration d'un fichier de journalisation

4. Restauration complète de la totalité d'une base de données en mode ARCHIVELOG 5. Restauration complète d'une partie d'une base de données en mode ARCHIVELOG 6. Restauration de tous les fichiers de contrôle en mode ARCHIVELOG

7. Restauration incomplète en mode ARCHIVELOG 8. Restauration en mode NOARCHIVELOG

9. Restauration à un emplacement différent 10. Tablespace temporaire géré localement Hypothèses de départ :

• la sauvegarde automatique du fichier de contrôle et du SPFILE est activée

• utilisation d'une zone de récupération rapide

• pas de base de données annexe pour stocker le repository RMAN

Remarque : si le fichier SPFILE, ou de contrôle, ou de journalisation est perdu, d'abord résoudre ces problèmes avant de traiter le cas des fichiers de données.

5.12.6.1. Scénario 1 : Restauration du SPFILE Deux possibilités :

• le recréer à partir d'un fichier de paramètres texte (méthode la plus simple)

• le restaurer à partir d'une sauvegarde RMAN Pour restaurer à partir d'une sauvegarde RMAN :

#positionner le DBID correspondant à la DB

RMAN > SET DBID <nombre> RMAN > SET DBID <nombre>

#démarrer l’instance sans la monter (RMAN va utiliser un spfile temporaire pour démarrer l’instance

RMAN > STARTUP NOMOUNT RMAN > STARTUP NOMOUNT

#restaurer le fichier de paramètres serveur à partir d’une sauvegarde automatique

RMAN > RESTORE SPFILE FROM AUTOBACKUP; RMAN > RESTORE SPFILE FROM AUTOBACKUP;

# si cela échoue, ou si utilisation d’une sauvegarde qui n’est pas une sauvegarde automatique, restaurer à partir d’une sauvegarde spécifique RMAN > RESTORE SPFILE FROM ‘<fichier>’;

# redémarrer l’instance et l’ouvrir RMAN > SHUTDOWN

RMAN > STARTUP

5.12.6.2. Scénario 2 : Restauration d'un fichier de contrôle

Dans le cas où l'on a perdu un ou plusieurs fichiers de contrôle mais qu'il en reste au moins un, il ne faut PAS repartir d'une sauvegarde de fichier de contrôle. Il faut simplement dupliquer un des fichiers de contrôle restants pour remplacer les fichiers perdus.

Mode opératoire :

1. Arrêter la base de données

2. Utiliser le fichier d'alerte de l'instance pour identifier les fichiers perdus

3. Dupliquer une version valide du fichier de contrôle pour la mettre à la place de celui endommagé 4. Redémarrer la base de données

Si le fichier de contrôle est dupliqué à un autre emplacement que celui d'origine, il faut modifier le paramètre CONTROL_FILES dans le fichier du SPFILE.

Mode opératoire :

1. Démarrer l'instance sans la monter

2. Modifier le paramètre CONTROL_FILES du SPFILE 3. Redémarrer l'instance

Exemple :

SQL > STARTUP NOMOUNT

SQL > ALTER SYSTEM SET CONTROL_FILES=

1 ‘<rep + nom fichier>’

2 ‘<nouveau rep et nom fichier>’

3 SCOPE=SPFILE;

SQL > SHUTDOWN IMMEDIATE SQL > STARTUP

5.12.6.3. Scénario 3 : Restauration d'un fichier de journalisation Même stratégie avec la recréation des fichiers.

Mode opératoire :

1. Identifier le/les fichier(s) endommagé(s) dans le fichier des alertes, dans le fichier de trace de LGWR ou dans la vue V$LOGFILE

2. Supprimer le membre endommagée

SQL > ALTER DATABASE DROP LOGFILE MEMBER ‘nom_fichier’;

3. Ajouter un nouveau membre au groupe concerné

SQL > ALTER DATABASE ADD LOGFILE MEMBER ‘nom_fichier’ TO GROUP numero;

4. Réitérer les deux opérations précédentes avec tous les membres endommagés

Remarque : on ne peut supprimer le membre si il appartient au groupe courant. Dans ce cas, il faut changer de groupe courant :

SQL > ALTER SYSTEM SWITCH LOGFILE

Cet ordre ne peut être exécuté que si la base de données est ouverte. Si la base de données est fermée, et qu'elle ne peut pas être ouverte tout de suite, on peut reporter la correction du problème à plus tard, 5.12.6.4. Scénario 4 : Restauration complète de la totalité d'une base de données en mode ARCHIVELOG Hypothèses :

• tous les fichiers de données perdus

• instance arrêtée Mode opératoire :

# monter la DB

RMAN STARTUP MOUNT RMAN > STARTUP MOUNT

# restaurer la DB

RMAN > RESTORE DATABASE;

# récupérer la DB #p

RMAN > RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 200M;

# ouvrir la DB

RMAN > SQL « ALTER DATABASE OPEN »;

5.12.6.5. Scénario 5 : Restauration complète d'une partie d'une base de données en mode ARCHIVELOG Hypothèse : perte d'un ou plusieurs fichiers de données (mais pas tous).

Il y a deux possibilités de réalisations selon la nature du problèmes :

• base fermée :

◦ fermée initialement

◦ fichier de données du tablespace SYSTEM ou UNDO

• base ouverte :

◦ autres fichiers de données

Restauration avec une base de données fermée :

• un fichier du tablespace SYSTEM est perdu

• mode opératoire :

# monter la DB

RMAN > STARTUP MOUNT

# restaurer fichiers de données souhaité via restore tablespace/datafile RMAN > RESTORE TABLESPACE system;

# récupérer les fichiers de données # récupérer les fichiers de données RMAN > RECOVER TABLESPACE system;

# ouvrir la DB

RMAN > SQL « ALTER DATABASE OPEN »;

Restauration avec une base de données ouverte :

• un fichier du tablespace INDEX est perdu

• mode opératoire :

◦ partie optionnelle si la base est déjà ouverte :

# monter la DB

RMAN > STARTUP MOUNT

# mettre offline les fichiers perdus

RMAN > SQL « ALTER DATABASE DATAFILE 6 OFFLINE »;

# ouvrir la DB # ouvrir la DB

RMAN > SQL « ALTER DATABASE OPEN »;

#mettre les TBS concernés offline

RMAN > SQL « ALTER DATABASE indx OFFLINE IMMEDIATE »;

#restaurer les fichiers de données souhaitées RMAN > RESTORE DATAFILE 6;

#récupérer les fichiers de données RMAN > RECOVER DATAFILE 6;

#passer ONLINE les tablespaces concernés RMAN > SQL « ALTER TABLESPACE indx ONLINE;

5.12.6.6. Scénario 6 : Restauration des fichiers de contrôle en mode ARCHIVELOG Hypothèses :

• perte de tous les fichiers de contrôle et un fichier de données

• on dispose de sauvegarde automatique du fichier de contrôle et les fichiers de journalisation en ligne sont disponibles

• l'instance est arrêtée Mode opératoire :

1. Positionner le SID correspondant 2. Démarrer l'instance sans la monter

3. Restaurer les fichiers de contrôle à partir d'une sauvegarde automatique 4. Monter la base de donnée

5. Restaurer les fichiers perdus

6. Récupérer la base de données (pas uniquement les fichiers de données car on repart d'une sauvegarde de fichier de contrôle; sous entendu un CROSSCHECK et CATALOG)

7. Ouvrir la base de données avec l'option « RESETLOGS » (obligatoire) Exemple :

RMAN > SET DBID <numero>

RMAN > STARTUP NOMOUNT

RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP;

RMAN > SQL « ALTER DATABASE MOUNT »;

5.12.6.7. Scénario 7 : Restauration incomplète en mode ARCHIVELOG

Hypothèse : tout est perdu : fichier SPFILE, fichier de contrôle, fichier de données, fichier de journalisation en ligne.

Ce type de restauration est nécessaire dans les cas suivants :

• perte de tous les redo log file

• perte d'un fichier de journalisation archivé nécessaire à une récupération

• retour avant un ordre SQL malencontreux (drop table, etc)

Dans tous les cas, il faut identifier le point de retour (SCN, timestamp, sequence) souhaité.

Mode opératoire : 1. Positionner le SID

2. Démarrer l'instance sans la monter

3. Restaurer le fichier de paramètres serveur

4. Redémarrer l'instance sans la monter (démarrage avec le SPFILE) 5. Restaurer les fichiers de contrôle

6. Monter la base

7. Synchroniser le référentiel RMAN avec le contenu de la zone Exemple :

RMAN > SET DBID <numero>

RMAN > STARTUP NOMOUNT

RMAN > RESTORE SPFILE FROM ‘<rep+nom fichier>’;

RMAN > STARTUP NOMOUNT FORCE;

RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP;

RMAN > SQL « ALTER DATABASE MOUNT »;

RMAN > CATALOG RECOVERY AREA NOPROMPT ; RMAN > CATALOG START WITH ‘rep’ NOPROMPT;

RMAN > SQL « ALTER DATABASE OPEN RESETLOGS »;

5.12.6.8. Scénario 8 : Restauration en mode NOARCHIVELOG Hypothèses :

• perte de tout ou une partie de la base de données

• mode noarchivelog

Solution : ramener la base de donnée à l'état où elle se trouvait lors de la dernière sauvegarde complète base fermée. Si les fichiers de journalisation sont disponibles et qu'il n'y a pas eu un cycle complet de basculement des fichiers de journalisation depuis la dernière sauvegarde, on peut alors tenter une restauration de type archivelog. Si la récupération signale une erreur, la situation est à priori désespérée.

Dans ce cas, on peut « tenter » une restauration en mode NOARCHIVELOG.

Mode opératoire : 1. Positionner le SID

2. Démarrer l'instance sans la monter

3. Restaurer les fichiers de contrôle à partir d'une sauvegarde automatique 4. Monter la base

5. Restaurer la base

6. (éventuellement) restauration incrémentale 7. Ouvrir la base de données avec option RESETLOGS Exemple :

RMAN > SET DBID <numero>

RMAN > STARTUP NOMOUNT

5.12.6.9. Scénario 9 : Restauration à un emplacement différent

Hypothèse : impossible de restaurer les fichiers de données dans l'arborescence d'origine.

Solution : utiliser deux commandes supplémentaires dans le processus de restauration (dans un bloc run) :

• Avant la restauration :

SET NEWNAME FOR DATAFILE ‘ancien’ TO ‘nouveau’;

• Après la restauration mais avant la récupération : SWITCH DATAFILE ALL;

Exemple : RUN {

STARTUP MOUNT

SET NEWNAME FOR DATAFILE <fichier> TO <fichier>.

RESTORE TABLESPACE data;

SWITCH DATAFILE ALL; SWITCH DATAFILE ALL;

RECOVER TABLESPACE data;

SQL « ALTER DATABASE OPEN »;

}

5.12.6.10. Scénario 10 : Tablespace temporaire géré localement

Les fichiers de données des tablespaces temporaires gérés localement ne sont jamais sauvegardés par RMAN et ne peuvent donc pas être restaurés.

Après une restauration, il faut donc recréer les fichiers de données des tablespaces gérés localement.

Dans le document Administration d'une base de données (Page 32-37)

Documents relatifs