Chapitre 13 Sauvegarde Et Récupération

Support de Cours ORACLE 11g : Administration, par Mawunya Koffi GBENOU
Chapitre 13 : Sauvegarde et récupération

• Principes
• Archivage des fichiers de journalisation
• Présentation du Recovery Manager
• Sauvegarde
• Le référentiel RMAN
• Récupération
• Les techniques de flashback
• Utiliser le Database Control
Principes
1. Vue d’ensemble
Assurer la sécurité des données est une des tâches principales de l’administrateur.
Cette sécurité est assurée par :
• la mise en œuvre d’une protection des fichiers sensibles de la base :

o fichiers de contrôle ;
o fichiers de journalisation.
• la mise en place d’une stratégie de sauvegarde/restauration :
o adaptée aux contraintes de l’entreprise ;
o testée et documentée.
La protection des fichiers de contrôle et des fichiers de journalisation s’effectue par multiplexage (voir
le chapitre Gestion des fichiers de contrôle et des fichiers de journalisation).
Les questions à se poser pour définir la stratégie sont les suivantes :
• Est-il acceptable de perdre des données ?

• Est-il possible d’arrêter périodiquement la base ?
• Est-il possible de réaliser une sauvegarde complète de la base pendant l’arrêt ?
La réponse à la question "est-il acceptable de perdre des données ?" est rarement "oui". Si
exceptionnellement, la réponse est "oui", il faut déterminer jusqu’à quelle limite : 1 jour, 2 jours, 1
semaine ?
Il est également nécessaire de déterminer la nature de l’activité sur la base :
• Les données sont-elles mises à jour quotidiennement par les utilisateurs ? C’est typiquement le
cas dans une application transactionnelle.
• Les données sont-elles mises à jour périodiquement (toutes les nuits, toutes les semaines) et
simplement consultées dans la journée ? C’est typiquement le cas avec une application
décisionnelle.
1 | P a g e


2. L’archivage des fichiers de journalisation
Comme nous l’avons déjà vu, les fichiers de journalisation constituent un journal des modifications
apportées à la base. Ils sont organisés en groupes écrits de manière circulaire : les informations
sauvegardées sont donc par défaut périodiquement écrasées.
Ces fichiers de journalisation peuvent être réappliqués à une sauvegarde de fichier de données, pour
rejouer toutes les modifications survenues entre la sauvegarde et un incident ayant endommagé le
fichier (restauration de média), à condition d’avoir conservé tous les fichiers de journalisation ; ceci
est possible en faisant fonctionner la base de données en mode ARCHIVELOG. Ce mode de
fonctionnement permet de garantir zéro perte de données en cas d’incident sur un fichier de données.
Le principe de récupération en mode ARCHIVELOG est le suivant :
À un instant T0, une sauvegarde d’un fichier de données est réalisée. Après T0, l’activité de mise à
jour se poursuit, générant des entrées dans les fichiers de journalisation. L’archivage étant activé, les
fichiers de journalisation pleins sont archivés.
À l’instant T1, un incident se produit et le fichier de données est perdu. La récupération du fichier de
données consiste à prendre la dernière sauvegarde du fichier (qui ne contient évidemment pas les
modifications effectuées depuis) et à appliquer sur cette sauvegarde les fichiers de journalisation
archivés (qui eux, contiennent la trace des modifications apportées depuis la dernière sauvegarde),
afin de ramener le fichier de données dans l’état où il se trouvait juste avant l’incident (pour être plus
précis, dans l’état de la dernière transaction validée).
3. Solutions de sauvegarde et récupération
Pour effectuer des sauvegardes et des récupérations, vous avez deux possibilités :
• utiliser l’outil Recovery Manager (RMAN) fourni par Oracle : c’est la méthode
recommandée ;
• procéder "à la main" avec des commandes du système d’exploitation et des scripts SQL.
2 | P a g e


RMAN est un outil ligne de commande qui facilite grandement les opérations de sauvegarde et de
récupération, en limitant notamment les risques de fausse manoeuvre. RMAN peut être utilisé à
travers une interface graphique dans le Database Control. Toutes les opérations de sauvegarde et de
récupération présentées dans cet ouvrage sont basées sur l’utilisation du Recovery Manager.
4. Stratégies de sauvegarde disponibles
Une sauvegarde peut être cohérente ou incohérente.
Une sauvegarde cohérente est une sauvegarde de la totalité de la base de données après un arrêt propre
de la base de données (pas après un SHUTDOWN ABORT ou un arrêt anormal de l’instance) ; ce
type de sauvegarde est aussi souvent appelé "sauvegarde base fermée". Après un arrêt propre de la
base de données, toutes les modifications ont été écrites dans les fichiers de données qui sont bien
synchrones. Une base de données restaurée à partir d’une sauvegarde cohérente peut être ouverte
immédiatement : il est inutile d’appliquer les fichiers de journalisation. C’est le seul mode de
sauvegarde disponible lorsque la base de données fonctionne en mode NOARCHIVELOG.
Une sauvegardeincohérente est une sauvegarde effectuée alors que la base de données est ouverte et
que l’activité de mise à jour se poursuit pendant la sauvegarde ; ce type de sauvegarde est aussi
souvent appelé "sauvegarde base ouverte". Les fichiers sauvegardés ne sont pas synchrones du point
de vue des modifications enregistrées. Lorsqu’une base de données est restaurée à partir d’une
sauvegarde incohérente, il faut appliquer les fichiers de journalisation pour rendre les fichiers
cohérents. Les sauvegardes incohérentes ne sont possibles que lorsque la base de données fonctionne
en mode ARCHIVELOG.
Une sauvegarde peut être complète, partielle ou incrémentale. Une sauvegarde complète est une
sauvegarde de la totalité de la base de données. Une sauvegarde partielle est une sauvegarde incluant
uniquement une partie de la base de données. Les sauvegardes partielles sont forcément incohérentes
entre elles. Pour qu’elles soient exploitables en restauration (ce qui est normalement l’objectif), il faut
que la base de données fonctionne en mode ARCHIVELOG. Une sauvegarde incrémentale est une
sauvegarde qui ne contient que les blocs modifiés depuis la dernière sauvegarde ; une sauvegarde
incrémentale peut être complète ou partielle.
Une sauvegarde cohérente complète nécessite de pouvoir arrêter la base de données et la sauvegarder
en totalité pendant l’arrêt.
5. Quelle stratégie pour le mode de fonctionnement de la base ?
Le tableau suivant résume les possiblités :
Pertes de données acceptables

Oui Non
Sauvegarde base ARCHIVELOG
Oui ARCHIVELOG
fermée possible NOARCHIVELOG
Non ARCHIVELOG ARCHIVELOG
Le mode ARCHIVELOG est obligatoire si au moins une des contraintes suivantes existe :
• Aucune perte de donnée n’est autorisée.

• La base de données ne peut pas être fermée pour être sauvegardée.
3 | P a g e


Le mode NOARCHIVELOG est possible si :
• Des pertes de données sont acceptables.

• La base de données peut être fermée pour être sauvegardée.
Un autre avantage du mode ARCHIVELOG est que la base de données peut rester ouverte lorsqu’un
incident survient sur un fichier de données qui n’appartient ni au tablespace SYSTEM, ni au
tablespace UNDO actif.
6. Quelle stratégie pour la sauvegarde ?
La première règle est de réaliser des sauvegardes fréquentes (au minimum tous les jours) et de
conserver plusieurs cycles de sauvegarde (en cas de problème avec une sauvegarde).
Si la base de données fonctionne en mode ARCHIVELOG, vous pouvez réaliser des sauvegardes
bases ouvertes ; il n’y a pas de raison de s’en priver.
Si la durée de sauvegarde et la taille des sauvegardes ne posent pas de problème (même en conservant
plusieurs sauvegardes), vous pouvez réaliser systématiquement (tous les jours) des sauvegardes
complètes.
Si la durée de sauvegarde et/ou la taille des sauvegardes posent un problème, vous pouvez réaliser des
sauvegardes incrémentales et/ou des sauvegardes partielles. Dans le cas de sauvegardes partielles,
vous devez simplement être très rigoureux dans le suivi et veiller à tout sauvegarder sur un cycle
complet de sauvegardes partielles.
Il est important de réaliser des sauvegardes très fréquemment pour pouvoir procéder à une restauration
en un temps raisonnable : partir d’une sauvegarde datant d’un mois et réappliquer tous les fichiers de
journalisation archivés depuis un mois risque de se révéler très long si la base de données est
activement mise à jour.
Archivage des fichiers de journalisation

1. Vue d’ensemble
Activer l’archivage des fichiers de journalisation s’effectue en mettant la base de données dans le
modeARCHIVELOG : ce mode permet de garantir qu’un groupe de fichiers de journalisation ne sera
pas réutilisé tant qu’il n’a pas été archivé.
Depuis la version 10, placer la base de données en mode ARCHIVELOG démarre automatiquement
deux processus d’archivage (ARC0 et ARC1) lors de l’ouverture de la base de données ; dans les
versions précédentes, il fallait le faire explicitement. Par contre, il est toujours opportun, même en
version 10, de positionner certains paramètres d’initialisation qui concernent les processus
d’archivage.
La base de données peut être créée d’entrée de jeu en mode ARCHIVELOG. Généralement, la base de
données est créée en mode NOARCHIVELOG puis passée en ARCHIVELOG. Archiver les fichiers
de journalisation générés par la création de la base de données présente un faible intérêt (mais un
volume d’archives important).
4 | P a g e


2. Mode opératoire
Le mode opératoire est le suivant :
• Modifier dans le fichier de paramètres serveur les paramètres d’initialisation qui concernent
les processus d’archivage
SQL> ALTER SYSTEM SET

2 log_archive_format=’redo_%S_%R_%T.arc’
3 SCOPE=SPFILE;
SQL> ALTER SYSTEM SET
2 log_archive_dest_1=’LOCATION=h:\oradata\arch\HERMES’
3 SCOPE=SPFILE;
• Arrêter proprement la base de données (pas ABORT)
SQL> SHUTDOWN IMMEDIATE
• Monter la base de données
SQL> STARTUP MOUNT
• Passer la base de données en mode ARCHIVELOG
SQL> ALTER DATABASE ARCHIVELOG;
• Sauvegarder la base de données (permet une sauvegarde T0 du nouveau mode de

fonctionnement de la base de données)
• Ouvrir la base de données
SQL> ALTER DATABASE OPEN;

Le mode ARCHIVELOG/NOARCHIVELOG est une propriété de la base qui se modifie par l’ordre SQL ALTER
DATABASE. Ce mode de fonctionnement est mémorisé dans le fichier de contrôle de la base de données ; il
n’est pas nécessaire de le repréciser à chaque démarrage.
L’ordre SQL ALTER DATABASE NOARCHIVELOGpermet, au besoin, de repasser en mode

NOARCHIVELOG.
3. Les paramètres du processus d’archivage
LOG_ARCHIVE_FORMAT
Ce paramètre définit le format souhaité pour le nom des archives.
Le format doit inclure les variables suivantes :
%s ou %S
Numéro de séquence du fichier de journalisation.
%t ou %T
5 | P a g e


Numéro d’instance (thread).
%r ou %R
Identifiant de remise à zéro des fichiers de journalisation (voir la section Récupération).
Lorsque le nom de la variable est en majuscules, le nombre est complété à gauche par des 0.
Exemple :
LOG_ARCHIVE_FORMAT = "redo_%S_%R_%T.arc"
LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST
Le paramètre LOG_ARCHIVE_DEST définit une première destination de l’archivage et le paramètre

LOG_ARCHIVE_DUPLEX_DEST une deuxième destination d’archivage (dupliquée). Ces
paramètres sont utilisables en Standard Edition.
Syntaxe
LOG_ARCHIVE_[DUPLEX_]DEST = "chemin_local"
Exemple :
LOG_ARCHIVE_DEST = "h:\oradata\arch\HERMES"
LOG_ARCHIVE_DEST_n (n de 1 à 10)
Ces paramètres définissent jusqu’à 10 destinations parallèles d’archivage. Ils sont utilisables
uniquement en Enterprise Edition.
Syntaxe simplifiée pour une destination locale (au moins une obligatoire)
LOG_ARCHIVE_DEST_n = "LOCATION=chemin_local"
Exemple :
LOG_ARCHIVE_DEST_1 = "LOCATION=h:\oradata\arch\HERMES"
Les paramètres LOG_ARCHIVE_DEST_n permettent de spécifier plusieurs destinations parallèles

pour les archives ; parmi les destinations, une au moins doit être locale. En dehors d’une destination
disque ou bande, il est possible de désigner une base de secours comme cible (configuration Data
Guard) ; cette technique avancée permet d’avoir une base de données sur un deuxième serveur vers
laquelle il est possible de basculer en cas de problème sur la base de données source : la base de
données de secours est mise à jour par transfert et application des fichiers de journalisation archivés.
Dans la spécification de la destination, il ne faut pas mettre d’espace autour du signe = dans la clause
LOCATION.
D’autres paramètres permettent de piloter le fonctionnement des destinations multiples (destinations

obligatoires, facultatives, nombre minimum de destinations réussies, etc.).
Remarques sur les destinations d’archivage
6 | P a g e


L’archivage direct sur bande pouvant être long (et bloquer >LGWR si l’archivage d’un fichier de
journalisation n’est pas terminé), une technique classique consiste à archiver sur disque, au niveau
d’Oracle, puis à transférer les archives sur bande au niveau du système d’exploitation (par un
processus non Oracle à mettre en place).
Les répertoires de destination ne sont pas créés par Oracle ; c’est à vous de le faire.
Si aucune destination d’archivage n’est définie, mais qu’une zone de récupération rapide soit spécifiée
(paramètre DB_RECOVERY_FILE_DEST), la zone de récupération rapide est utilisée comme
destination d’archivage.
ARCHIVE_LAG_TARGET
Ce paramètre permet de définir une durée maximale en secondes entre deux archivages.
Une valeur nulle désactive la fonctionnalité (valeur par défaut). Les valeurs autorisées sont comprises
entre 60 (une minute) et 7 200 (2 heures). Ce paramètre permet de forcer l’archivage de façon
périodique et donc de garantir une périodicité d’archivage stable, indépendante de la fréquence de
basculement des fichiers de journalisation qui peut varier en fonction du moment de la journée.
Exemple :
ARCHIVE_LAG_TARGET = 1800 # 30 minutes
S’il n’y a rien à archiver, Oracle ne génère pas d’archive.
À l’origine, ce paramètre est destiné au fonctionnement de l’instance dans une configuration Data
Guard. Dans cette configuration, le paramètre ARCHIVE_LAG_TARGET détermine la durée
maximale d’informations de journalisation qui seraient perdues (non transférées sur la base de
données de secours) en cas de plantage de la base de données principale.
Le paramètre fonctionne même si la configuration Data Guard n’est pas utilisée, et même s’il n’y a
pas archivage ; dans ce dernier cas, le paramètre conditionne la fréquence de basculement des fichiers
de journalisation.
4. Trouver des informations sur l’archivage
Dans SQL*Plus, vous pouvez utiliser la commande ARCHIVE LOG LIST(dans une connexion
SYSDBA) pour obtenir des informations sur l’archivage ;
SQL> CONNECT / AS SYSDBA

Connecté.
SQL> ARCHIVE LOG LIST
mode Database log mode Archive
Archivage automatique Activé
Destination de l’archive h:\oradata\arch\HERMES
Séquence de journal en ligne la plus ancienne 19
Séquence de journal suivante à archiver 21
Séquence de journal courante 21
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur l’archivage :
• V$DATABASE : mode de fonctionnement de la base de données (colonne LOG_MODE) ;>
7 | P a g e


• V$LOG : statut des groupes vis-à-vis de l’archivage (colonne ARCHIVED) ;<

• V$ARCHIVED_LOG : informations sur les fichiers de journalisation archivés ;
• V$ARCHIVE_DEST : informations sur les destinations d’archivage.
Les colonnes intéressantes de la vue V$ARCHIVED_LOG sont les suivantes :
RECID
Identifiant de l’enregistrement.
NAME
Chemin complet de l’archive.
SEQUENCE#
Numéro de séquence du fichier de journalisation correspondant.
FIRST_CHANGE#
Plus petit numéro SCN écrit dans l’archive.
FIRST_TIME
Date et heure du plus petit numéro SCN.
NEXT_CHANGE#
Plus grand numéro SCN écrit dans l’archive.
NEXT_TIME
Date et heure du plus grand numéro SCN.
COMPLETION_TIME
Date et heure de l’archivage.
Les colonnes intéressantes de la vue V$ARCHIVE_DEST sont les suivantes :
DEST_NAME
Nom de la destination.
DESTINATION
Chemin de la destination.
STATUS
Statut de la destination (VALID, ERROR, etc.).
8 | P a g e


ERROR
Message d’erreur (en cas d’erreur).
Exemple :
SQL> SELECT log_mode FROM v$database;

LOG_MODE
------------
ARCHIVELOG
SQL> SELECT group#,sequence#,status,archived

2 FROM v$log;
GROUP# SEQUENCE# STATUS ARC
---------- ---------- ---------------- ---
1 25 INACTIVE YES
2 26 CURRENT NO
3 24 INACTIVE YES
SQL> SELECT sequence#,name FROM v$archived_log;

SEQUENCE# NAME
---------- ----------------------------------------------------
20 H:\ORADATA\ARCH\HERMES\REDO_00020_0545650779_001.ARC
...
SQL> SELECT destination,status,error FROM v$archive_dest
2 WHERE dest_name=’LOG_ARCHIVE_DEST_1’;
DESTINATION
---------------------------------------------------------
STATUS ERROR
--------- -----------------------------------------------
h:\oradata\arch\HERMES
ERROR ORA-19504: échec de création du fichier ""
5. Problème courant et solution
L’archivage peut être bloqué lorsqu’il y a un problème avec la destination d’archivage :
• plus d’espace disponible ;

• destination inaccessible.
Cela peut conduire à un blocage de LGWR si tous les fichiers de journalisation en ligne ont besoin
d’être archivés.
Une telle situation est détectable grâce à la vue V$ARCHIVE_DEST (colonne STATUS) ou par des
messages dans le fichier des alertes de l’instance :
Sun Aug 3 12:43:25 2008

Errors in file d:\oracle\admin\hermes\bdump\hermes_arc1_1504.trc:
ORA-19504: échec de création du fichier "H:\ORADATA\ARCH\HERMES\
REDO_00029_0545650779_001.ARC"
ORA-27044: impossible d’écrire le bloc d’en-tête du fichier
OSD-04008: échec de Writefile() ; écriture impossible dans le fichier
O/S-Error: (OS 112) Espace insuffisant sur le disque.
Pour débloquer la situation, il suffit de résoudre le problème qui existe sur la destination d’archivage,
par exemple en déplaçant des archives vers une autre destination afin de libérer de l’espace.
9 | P a g e


Si vous ne pouvez pas résoudre le problème avec la destination d’archivage, modifiez temporairement
la destination d’archivage :
ALTER SYSTEM SET

log_archive_dest_1=’LOCATION=d:\temp’
SCOPE=MEMORY;
Il peut être nécessaire ensuite d’exécuter l’ordre SQL ALTER SYSTEM ARCHIVE LOG START
pour relancer le processus d’archivage.
Présentation du Recovery Manager

1. Introduction
RMAN est un outil ligne de commande qui permet de réaliser des sauvegardes et des récupérations
d’une base de données appelée base de données cible (target database).
RMAN utilise un référentiel (repository) pour stocker des informations sur sa configuration, les
sauvegardes réalisées, la structure de la base cible, les fichiers de journalisation archivés, etc.
Ce référentiel est toujours stocké dans le fichier de contrôle de la base cible. La durée de conservation
des informations dans le fichier de contrôle est déterminée par le paramètre d’initialisation
CONTROL_FILE_RECORD_KEEP_TIME (7 jours par défaut).
Le référentiel peut aussi être stocké dans un catalogue de récupération (recovery catalog) qui se
matérialise par un schéma dans une autre base de données. Un seul catalogue de récupération peut être
utilisé pour centraliser les référentiels RMAN de plusieurs bases de données cibles. Employer un
catalogue de récupération séparé est intéressant car les informations de sauvegarde sont préservées si
tous les fichiers de contrôle de la base cible sont perdus.
Les fichiers de contrôle sont donc encore plus importants lorsque vous utilisez RMAN sans catalogue de
récupération. Si vous perdez tous les fichiers de contrôle de la base cible, RMAN n’a plus d’informations sur
les sauvegardes disponibles. Si vous repartez d’une sauvegarde de fichier de contrôle, RMAN n’aura pas
d’informations sur les sauvegardes réalisées après la sauvegarde du fichier de contrôle. Si vous n’utilisez pas
de catalogue de récupération, vous avez également intérêt à augmenter la valeur du paramètre
CONTROL_FILE_RECORD_KEEP_TIME (au moins 10 à 15 jours).
Si vous définissez une zone de récupération rapide (flash recovery area), à l’aide des paramètres
DB_RECOVERY_FILE_DEST et DB_RECOVERY_FILE_DEST_SIZE, vous pouvez bénéficier des
fonctionnalités de sauvegarde et de restauration automatiques sur disque proposées par RMAN. En
complément, vous pouvez définir une politique de conservation (retention policy) indiquant combien
de temps une sauvegarde doit être conservée. RMAN se charge alors de gérer l’espace de la zone de
récupération rapide en supprimant, si nécessaire, les sauvegardes obsolètes ou les sauvegardes
recopiées sur bande.
Pour chaque opération de sauvegarde, copie, restauration, RMAN utilise un canal (channel). Un canal
est une connexion entre le client RMAN et un processus serveur de la base de données cible qui
accède à un périphérique (disque ou bande).
10 | P a g e


Une sauvegarde RMAN peut se faire sous la forme d’une copie image (image copy) ou d’un jeu de
sauvegarde (backup set). Une copie image est une copie à l’identique du fichier (analogue à une copie
par une commande du système d’exploitation). Un jeu de sauvegarde contient un ou plusieurs fichiers
sauvegardés. Un jeu de sauvegarde comprend un ou plusieurs fichiers ; chaque fichier d’un jeu est
appelé élément de sauvegarde (backup piece). Par défaut, un jeu de sauvegarde comprend un seul
élément de sauvegarde, mais il est possible de limiter la taille de ces éléments ; dans ce cas, un jeu de
sauvegarde peut contenir plusieurs éléments de sauvegarde si la taille totale de la sauvegarde est
supérieure à la limite. Le jeu de sauvegarde a un format propriétaire RMAN.
Pour réaliser des sauvegardes sur bande, RMAN s’interface avec un logiciel de gestion de média
fourni par le vendeur du système de sauvegarde.
RMAN offre un très grand nombre de fonctionnalités et d’options et peut être utilisé de différentes
manières. Dans cet ouvrage, nous présenterons les fonctionnalités de base de RMAN, nécessaires et
suffisantes pour mettre en place des stratégies de sauvegarde/récupération simples, adaptées à un
grand nombre de cas. Nous supposerons notamment qu’une zone de récupération rapide a été définie,
ce qui permet de simplifier un grand nombre d’opérations, et qu’aucun catalogue de récupération
séparé n’a été mis en place.
Les fonctionnalités de base de RMAN sont décrites dans la documentation Oracle® Database Backup
and Recovery User’s Guide.
2. Lancer RMAN
Pour lancer RMAN, il suffit d’exécuter la commande rman à l’invite du système d’exploitation.
Syntaxe
rman [liste_options]
Les options suivantes peuvent être utilisées :
TARGET [=] connexion
Chaîne de connexion à la base de données cible.
CATALOG [=] connexion
Chaîne de connexion à la base de données du catalogue de récupération.
CMDFILE [=] fichier
Chemin vers un fichier contenant des commandes RMAN à exécuter.
LOG [=] fichier
Chemin vers un fichier journal de l’activité RMAN.
APPEND
Indique que le fichier journal doit être ouvert en mode ajout.
11 | P a g e


USING valeur [...]
Définit une ou plusieurs valeurs pour des variables de substitution qui peuvent être utilisées dans un
fichier de commandes RMAN. Dans le fichier de commande RMAN, les variables de substitution sont
définies par la syntaxe &n (éventuellement suivi d’un point), n étant un entier.
Les principes de connexion à la base cible sont les mêmes qu’avec SQL*Plus : utilisation par défaut des
variables d’environnement (ORACLE_SID, LOCAL, TWO_TASK), utilisation d’un nom de service réseau, etc. Les
variables d’environnement comme NLS_DATE_FORMATetNLS_LANG influent aussi sur le format des dates et
la langue des messages affichés par RMAN. Par ailleurs, la connexion à la base cible s’effectue implicitement
AS SYSDBA.
Exemple :
• Lancer RMAN sans se connecter
> rman
Recovery Manager: Release 11.1.0.6.0 - Production
on Lun. Août 4 07:37:14 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN>
• Lancer RMAN en se connectant à la base cible (utilisation des variables d’environnement et

authentification SYSDBA par le système d’exploitation)
> rman target /

Recovery Manager: Release 11.1.0.6.0 - Production
on Lun. Août 4 07:48:22 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connecté à la base de données cible : HERMES ( DBID=3535892647)
• Lancer RMAN en se connectant à la base cible (utilisation d’un nom de service réseau et
authentification SYSDBA par un fichier de mot de passe)
> rman target sys/wX#12@hermes

...
• Lancer RMAN et exécuter un fichier de commande (qui effectue la connexion)
> rman cmdfile=backup.rcv log=backup.log append

...
Si vous n’utilisez pas l’option CMDFILE, RMAN est lancé en mode interactif ; il affiche une invite et
vous pouvez saisir des commandes. Avec l’option CMDFILE, RMAN est lancé en mode batch ; il
exécute les commandes contenues dans le fichier de commande puis quitte.
Chaque base de données possède un identifiant unique appelé DBID. Le DBID de la base cible est affiché par
RMAN lorsque vous vous connectez. Vous avez intérêt à noter ce DBID quelque part, il peut en effet se révéler
utile pour certaines opérations.
12 | P a g e


3. Quelques commandes utiles
Certaines commandes RMAN doivent se terminer par un point-virgule, d’autres non (point-virgule
optionnel). Les commandes RMAN nécessitant un point-virgule peuvent être saisies sur plusieurs
lignes, les autres non. Les commandes RMAN sont saisies indifféremment en majuscules ou en
minuscules.
Les commandes suivantes peuvent être utilisées dans RMAN :
@fichier
Exécute un fichier de commande.
@@fichier
Exécute un fichier de commande dans le même répertoire que le fichier de commande actuel.
SET ECHO ON | OFF
Active ou désactive l’écho des commandes.
SPOOL LOG TO fichier [APPEND]
Écrit la sortie RMAN dans un fichier.
SPOOL LOG OFF
Arrête l’écriture de la sortie RMAN dans un fichier.
STARTUP [option]
Démarre la base de données ; les options sont les mêmes que dans SQL*Plus.
SHUTDOWN [option]
Arrête la base de données ; les options sont les mêmes que dans SQL*Plus.
ALTER DATABASE MOUNT | OPEN ;
Monte ou ouvre une base de données.
CONNECT CATALOG connexion
Établit une connexion à la base de données du catalogue.
CONNECT TARGET connexion
Établit une connexion à la base de données cible.
HOST [’commande’] ; HOST ["commande"] ;
13 | P a g e


Exécute une commande du système d’exploitation ou ouvre une session du système d’exploitation (si
aucune commande n’est spécifiée).
SQL ’requête’ ; SQL "requête" ;
Exécute une requête SQL sur la base de données cible. La requête ne doit pas se terminer par un point-
virgule ; si elle contient des apostrophes, elles doivent être doublées.
EXIT ou QUIT
Quitte RMAN.
Exemple de script RMAN:
# ceci est un commentaire

SPOOL LOG TO d:\rman.log
SET ECHO ON
CONNECT TARGET /
SHUTDOW MOUNT
SQL "ALTER DATABASE ARCHIVELOG";
ALTER DATABASE OPEN;
SPOOL LOG OFF
SET ECHO OFF
Si vous souhaitez placer un commentaire en fin de ligne, vous devez terminer la commande par un
point-virgule (même si le point-virgule est optionnel pour la commande).
Par ailleurs, il est possible de grouper des commandes RMAN dans un bloc délimité par des accolades
et d’exécuter ce bloc avec la commande RUN :
RUN
{
...
}
Certaines commandes (ALLOCATE CHANNEL, SET) exécutées à l’intérieur d’un bloc ont une
portée limitée au bloc. Par ailleurs, si une commande du bloc échoue, l’exécution du bloc s’arrête.
Certaines commandes RMAN doivent être exécutées à l’intérieur d’un bloc (ALLOCATE CHANNEL
par exemple) ; d’autres ne peuvent pas être exécutées dans un bloc (SPOOL par exemple).
4. Configurer RMAN
RMAN dispose de plusieurs réglages persistants utilisés par défaut lors des différentes opérations.
La configuration actuelle peut être visualisée en exécutant la commande SHOW ALL.
Exemple :
RMAN> SHOW ALL ;

utilisation du fichier de contrôle de la base
de données cible au lieu du catalogue de récupération
les paramètres de configuration RMAN de la base
de données ayant le db_unique_name HERMES sont les suivants :
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
14 | P a g e


CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ’%F’; #
default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ’AES128’; # default
CONFIGURE COMPRESSION ALGORITHM ’BZIP2’; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ’D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\
DATABASE\SNCFHERMES.ORA’; # default
Le commentaire # default indique que le paramètre est égal à sa valeur par défaut.
La commande CONFIGURE permet de modifier les réglages persistants ; la commande SHOW ALL
montre la valeur des réglages en utilisant la syntaxe de la commande CONFIGURE.
Les principaux réglages sont les suivants :
Configurer les canaux et les périphériques
Par défaut, le périphérique utilisé est le disque (paramètre DEFAULT DEVICE TYPE), la destination
par défaut des sauvegardes étant la zone de récupération rapide. Si cette dernière n’est pas définie,
RMAN utilise une destination par défaut qui dépend de la plate-forme.
Si vous souhaitez configurer la destination de sauvegarde, vous pouvez utiliser la commande

suivante :
CONFIGURE CHANNEL DEVICE TYPE DISK options ;
La clause options peut prendre une ou plusieurs valeurs dont :
FORMAT ’format’
Chemin et format de nom de fichier pour la sauvegarde.
MAXPIECESIZE taille [K|M|G]
Taille maximale des éléments de sauvegarde. Aucune limite par défaut.
Exemple :
CONFIGURE CHANNEL DEVICE TYPE DISK

FORMAT ’h:\backup\%U’
MAXPIECESIZE 2G ;
Dans cet exemple, la taille des éléments de sauvegarde est limitée à 2 Go. Si la taille de la sauvegarde
est supérieure à 2 Go, le jeu de sauvegarde contiendra plusieurs éléments de sauvegarde.
L’option format comprend un chemin et un format de fichier. Le format de fichier utilise

généralement une ou plusieurs des variables suivantes :
15 | P a g e


%U
Nom de fichier unique dont la composition dépend de la nature de la sauvegarde :
- %u_%p_%c pour un élément de sauvegarde ;
- data-D-%d_id-%I_TS-%N_FNO-%f_%u pour une copie image d’un fichier de données ;
- arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u pour une copie image d’un fichier de journalisation

archivé ;
- cf-D_%d-id-%I_%u pour une copie image du fichier de contrôle.
%d
Nom de la base de données.
%I
Identifiant de la base de données (DBID).
%h
Numéro d’activation de la base de données.
%N
Nom du tablespace.
%f
Numéro de fichier de données.
%e
Numéro de séquence du fichier de journalisation archivé.
%h
Numéro d’instance (thread) du fichier de journalisation archivé.
%s
Numéro du jeu de sauvegarde (backup set).
%p
Numéro de l’élément de sauvegarde (backup piece) à l’intérieur d’un jeu de sauvegarde.
%c
16 | P a g e


Numéro de copie de l’élément de sauvegarde (cas d’une sauvegarde multiplexée). 1 si la sauvegarde

n’est pas multiplexée.
%u
Chaîne unique de 8 caractères basée sur le numéro du jeu de sauvegarde ou de la copie image et de la
date/heure de la sauvegarde/copie.
Si vous utilisez des formats personnalisés, assurez‐vous que le nom de fichier généré est unique, sous peine
d’écraser d’autres sauvegardes.
Dans la commande CONFIGURE CHANNEL DEVICE TYPE DISK, une option non spécifiée est
remise à sa valeur par défaut ; la valeur précédente n’est pas conservée.
Pour modifier la taille maximale des éléments de sauvegarde, en remettant le format par défaut, vous
pouvez utiliser la commande suivante :
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 4G ;
Pour revenir à la configuration par défaut, vous pouvez employer la commande suivante :
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR ;

Configurer la politique de conservation
La politique de conservation peut être définie en termes de fenêtre de restauration ou de redondance.
Une fenêtre de restauration indique jusqu’à combien de jours dans le passé vous souhaitez pouvoir
revenir. Une redondance indique combien de sauvegardes de chaque fichier doivent être
conservées ; c’est la politique par défaut (avec une redondance de 1).
Pour définir la politique de conservation, utilisez une des commandes suivantes :
• Fenêtre de restauration
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS ;
• Redondance
CONFIGURE RETENTION POLICY TO REDUNDANCY n ;
Lorsque la zone de récupération rapide est utilisée, RMAN supprime automatiquement les
sauvegardes obsolètes (s’il a besoin de place), en s’appuyant sur la politique de conservation par
défaut et sur la taille allouée à la zone de récupération rapide (paramètre
DB_RECOVERY_FILE_DEST_SIZE).
Pour revenir à la configuration par défaut, vous pouvez utiliser la commande suivante :
CONFIGURE RETENTION POLICY CLEAR ;

Configurer la sauvegarde automatique du fichier de contrôle
La sauvegarde automatique du fichier de contrôle peut être activée grâce à la commande suivante :
17 | P a g e


CONFIGURE CONTROLFILE AUTOBACKUP ON ;
Lorsque la sauvegarde automatique du fichier de contrôle est activée, le fichier de contrôle est, par
défaut, sauvegardé dans la zone de récupération rapide.
Si vous souhaitez définir une destination de sauvegarde par défaut spécifique, vous pouvez utiliser la
commande suivante :
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ’format’ ;
L’option format ne peut et ne doit inclure que la variable %F (nom unique basé sur l’identifiant de la
base de données, la date et un numéro de séquence hexadécimal). Remplacez TO ’format’ par CLEAR
pour revenir au format par défaut.
Activer la sauvegarde automatique du fichier de contrôle active aussi la sauvegarde automatique du

fichier de paramètres serveur. Lorsque la sauvegarde automatique est activée, ces deux fichiers sont
automatiquement sauvegardés à chaque fois qu’une modification de structure de la base de données
ou une sauvegarde RMAN est enregistrée dans le fichier de contrôle.
Activer la sauvegarde automatique du fichier de contrôle est vivement conseillé, surtout si vous n’utilisez pas
de catalogue de récupération séparé pour RMAN. En cas de perte de tous les fichiers de contrôle, RMAN
pourra restaurer ces derniers à partir d’une sauvegarde automatique.
5. Utilisation de la zone de récupération rapide
Oracle conseille vivement d’utiliser une zone de récupération rapide pour bénéficier d’un certain
nombre de fonctionnalités automatiques relatives aux opérations de sauvegarde et de récupération.
Si une zone de récupération rapide est configurée, elle est utilisée comme destination par défaut des
sauvegardes et de plusieurs autres fichiers (par exemple, les fichiers de journalisation archivés si
aucune destination d’archivage n’est définie).
Le quota d’espace alloué à la zone de récupération rapide (paramètre DB_RECOVERY_

FILE_DEST_SIZE) doit être spécifié avec soin, en tenant compte de la taille des fichiers qui y sont
stockés (sauvegardes notamment) et de la politique de conservation des sauvegardes.
Du point de vue de la sécurité, il est vivement conseillé d’utiliser un disque séparé pour la zone de
récupération rapide.
Les fichiers générés par Orale dans la zone de récupération rapide sont stockés dans différents sous-
répertoires, avec des formats de nom de fichiers spécifiques. Ce sont des fichiers "gérés par Oracle"
(Oracle-Managed Files).
Les différents répertoires sont définis sous la forme suivante :
• <DB_UNIQUE_NAME>/<type>[/<date>] (Unix/Linux) ;
• <DB_UNIQUE_NAME>\<TYPE>[\<date>] (Windows).
18 | P a g e


Avec :
<DB_UNIQUE_NAME>
Nom unique de la base de données tel que défini par le paramètre DB_UNIQUE_NAME (par défaut
égal au paramètre> DB_NAME).
<type>
Sous-répertoire correspondant au type de fichier : archivelog (fichier de journalisation archivé),

autobackup (sauvegarde automatique du fichier de contrôle et du fichier de paramètres serveur),
backupset (jeu de sauvegarde), controlfile (copie image de fichier de contrôle), datafile (copie image
de fichier de données).
<TYPE>
Identique à <type> mais en majuscules.
<date>
Sous-répertoire correspondant à la date (au format AAAA_MM_JJ). N’existe pas pour les répertoires
controlfile et datafile.
Les règles de nommage des fichiers gérés par Oracle sont les suivantes :
Type de fichier Format

Fichier de journalisation archivé o1_mf__<s>__.log
Copie image de fichier de données o1_mf_<t>__.dbf
Copie image de fichier de contrôle o1_mf_<a>__.ctl
Jeu de sauvegarde o1_mf_<c>_<a>__.bkp
Sauvegarde automatique o1_mf_s_<h>__.bkp
Avec :
<t>
nom du tablespace ;

chaîne de 8 caractères qui garantit l’unicité ;
<g>
numéro de groupe pour les fichiers de journalisation ;

numéro d’instance (thread) pour les fichiers de journalisation archivés ;
<s>
19 | P a g e


numéro de séquence pour les fichiers de journalisation archivés ;
<a>
nom donné à la sauvegarde (option TAG de la commande BACKUP) ;
<c>
chaîne de 5 caractères correspondant au contenu du jeu de sauvegarde ;
<h>
horodatage de la sauvegarde automatique (nombre de secondes écoulées depuis une date interne fixe).
Exemple :
H:\ORADATA\FLASH_RECOVERY_AREA\HERMES
ARCHIVELOG
2008_08_05
O1_MF_1_35_49HPDHY8_.ARC
AUTOBACKUP
2008_08_05
O1_MF_S_661934919_49HPX9N0_.BKP
BACKUPSET
2008_08_05
O1_MF_NNNDF_TAG20080805T064838_49HPX6TV_.BKP
CONTROLFILE
O1_MF_TAG20080805T065123_49HQ2C9R_.CTL
DATAFILE
O1_MF_TEST_49HQ0498_.DBF
La même zone de récupération rapide peut être partagée par plusieurs bases de données, sous réserve
que ces dernières aient un nom unique de base de données (paramètre DB_UNIQUE_NAME)
différent.
6. La commande VALIDATE
La commande VALIDATE peut être utilisée dans différentes situations (à titre préventif, avant une
sauvegarde, avant une restauration, etc.) pour détecter d’éventuels problèmes de corruption ou de
fichiers manquants.
Syntaxe simplifiée
VALIDATE quoi ;
La clause quoi peut prendre une des valeurs suivantes (non exhaustif) :
DATABASE
Vérification de la totalité de la base de données (fichiers de données, fichiers de contrôle et fichier de

paramètre serveur).
TABLESPACE liste_noms
20 | P a g e


Vérification d’un ou plusieurs tablespaces.
DATAFILE liste_numéros_ou_noms
Vérification d’un ou plusieurs fichiers de données.
CURRENT CONTROLFILE
Vérification du fichier de contrôle courant.
SPFILE
Vérification du fichier de paramètres serveur.
ARCHIVELOG ALL
Vérification de tous les fichiers de journalisation archivés (ALL peut être remplacé par différentes
clauses permettant de sélectionner les fichiers de journalisation archivés à vérifier).
BACKUPSET liste_clés
Vérification d’un ou plusieurs jeux de sauvegarde.
RECOVERY AREA
Vérification de tous les fichiers stockés dans la zone de récupération rapide.
Exemples
VALIDATE DATABASE ;
VALIDATE DATAFILE 1,’E:\ORADATA\HERMES\DATA01.DBF’ ;
VALIDATE TABLESPACE system,sysaux ;
VALIDATE BACKUPSET 47,52 ;
Sauvegarde
1. Généralités
La commande BACKUP permet d’effectuer une sauvegarde. Pour que cette commande fonctionne, il
faut que la base de données soit montée ou ouverte car RMAN a besoin d’accéder au fichier de
contrôle de la base cible, notamment pour y enregistrer l’existence de la sauvegarde. Les sauvegardes
base ouverte ne sont possibles que si la base de données fonctionne en mode ARCHIVELOG. Si la
base de données fonctionne en mode NOARCHIVELOG, il faut au préalable arrêter la base de
données (proprement) puis la monter :
SHUTDOWN IMMEDIATES
TARTUP MOUNT
BACKUP ... ;
RMAN peut sauvegarder des fichiers de données, des fichiers de contrôle, des fichiers de
journalisation archivés, le fichier de paramètres serveur ou des éléments de sauvegarde (d’une
21 | P a g e


sauvegarde précédente). Comme indiqué précédemment, une sauvegarde RMAN peut être réalisée
sous la forme d’une copie image (image copy) ou d’un jeu de sauvegarde (backup set). Par défaut, la
sauvegarde s’effectue dans un jeu de sauvegarde.
Lorsque RMAN effectue une sauvegarde de fichiers de données dans un jeu de sauvegarde, il ne
sauvegarde pas les blocs jamais utilisés des fichiers, ce qui permet de gagner de la place. En
complément, il est possible de compresser le jeu de sauvegarde ; cela ralentit légèrement la
sauvegarde, consomme un peu de CPU, mais diminue la taille de la sauvegarde de manière importante
(typiquement, division par 5). Ces deux fonctionnalités ne sont pas disponibles dans le cas d’une copie
image (copie bit à bit du fichier d’origine).
La syntaxe générale de la commande BACKUP est la suivante :
BACKUP [comment] quoi [option]

La commande BACKUP propose un très grand nombre d’options. Dans cet ouvrage, nous ne présenterons que
les options les plus couramment utilisées.
La clause comment peut prendre une ou plusieurs des valeurs suivantes :
INCREMENTAL LEVEL n [CUMULATIVE]
Indique que la sauvegarde est une sauvegarde incrémentale.
VALIDATE
Indique simplement de vérifier que la sauvegarde peut être réalisée (teste la présence des fichiers et
leur non-corruption). Cette option est équivalente à l’utilisation de la commande VALIDATE.
AS COPY ou AS [COMPRESSED] BACKUPSET
Indique s’il faut faire une sauvegarde sous la forme d’une copie image ou d’un jeu de sauvegarde,
éventuellement compressé.
La clause quoi peut prendre une ou plusieurs des valeurs suivantes :
DATABASE
Sauvegarde de la totalité de la base de données.
TABLESPACE cible
Sauvegarde d’un ou plusieurs tablespaces.
DATAFILE cible
Sauvegarde d’un ou plusieurs fichiers de données.
CURRENT CONTROLFILE
Sauvegarde du fichier de contrôle courant.
22 | P a g e


SPFILE
Sauvegarde du fichier de paramètres serveur.
ARCHIVELOG cible
Sauvegarde des fichiers de journalisation archivés.
La clause option peut prendre une ou plusieurs des valeurs suivantes :
INCLUDE CURRENT CONTROLFILE
Inclure le fichier de contrôle courant dans la sauvegarde.
PLUS ARCHIVELOG
Inclure les fichiers de journalisation archivés dans la sauvegarde.
DELETE [ALL] INPUT
Supprimer les éléments sauvegardés (valable uniquement pour une sauvegarde de fichiers de
journalisation archivés ou une sauvegarde de jeu de sauvegarde).
FORMAT [=] ’format’
Spécifier un format pour la sauvegarde (chemin et format de nom de fichier).
TAG [=] ’nom’
Associer un nom à la sauvegarde.
NOT BACKED UP clause_depuis
Indiquer de ne sauvegarder que les éléments qui n’ont pas été sauvegardés un certain nombre de fois
ou depuis un certain temps.
Dans la commande BACKUP, la seule clause obligatoire est la clause quoi qui indique ce qu’il faut
sauvegarder. Toutes les autres clauses sont optionnelles et ont des valeurs par défaut.
Certaines valeurs par défaut proviennent de la configuration persistante de RMAN. C’est le cas
notamment de la destination de la sauvegarde et du format du nom des fichiers (canal par défaut).
L’option FORMAT de la commande BACKUP permet de spécifier une destination différente pour la
sauvegarde. Sauf modification de la configuration, la sauvegarde sur disque s’effectue par défaut dans
un jeu de sauvegarde non compressé (équivalent à l’option AS BACKUPSET). Pour effectuer une
sauvegarde dans un jeu de sauvegarde compressé, il faut utiliser l’option AS COMPRESSED
BACKUPSET (BACKUP AS COMPRESSED BACKUPSET ...). Pour effectuer une sauvegarde sous
la forme d’une copie image, il faut utiliser l’option AS COPY (BACKUP AS COPY ...).
Avec l’option VALIDATE, la commande BACKUP n’effectue en fait aucune sauvegarde ; elle vérifie
simplement qu’une sauvegarde pourrait être réalisée, c’est-à-dire que les fichiers à sauvegarder sont
bien accessibles et ne sont pas corrompus.
23 | P a g e


L’optionTAG permet d’associer un nom à la sauvegarde, ce qui permet par la suite d’identifier
facilement des sauvegardes ou des catégories de sauvegarde. Ce nom est inclus dans les noms de
fichiers générés par RMAN lors d’une sauvegarde dans la zone de récupération rapide.
L’option NOT BACKED UP propose deux syntaxes :
• NOT BACKED UP SINCE TIME = ’date’ ;

• NOT BACKED UP n TIMES.
La première syntaxe permet de ne sauvegarder que les éléments qui n’ont pas été sauvegardés depuis
un certain temps. L’option date peut être une constante conforme au format de date par défaut
(NLS_DATE_FORMATde la session RMAN) ou une expression (du type ’SYSDATE-1’). La
deuxième syntaxe permet de ne sauvegarder que les éléments qui n’ont pas été sauvegardés un certain
nombre de fois ; cette syntaxe ne peut être utilisée que pour les fichiers de journalisation archivés.
Les autres clauses sont détaillées dans les points suivants.
Lors de chaque sauvegarde, RMAN affiche de nombreuses informations sur les opérations effectuées.
Exemple
RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE TAG=’DBF’;

Démarrage de backup dans 05/08/08
utilisation du canal ORA_DISK_1
canal ORA_DISK_1 : démarrage de l’ensemble de sauvegarde compressé de tous
les fichiers de données
canal ORA_DISK_1 : insertion du(des) fichier(s) de données dans l’ensemble
de sauvegarde
fichier de données en entrée, numéro=00001,
nom=E:\ORADATA\HERMES\SYSTEM01.DBF
nom=E:\ORADATA\HERMES\SYSAUX01.DBF
nom=E:\ORADATA\HERMES\UNDOTBS01.DBF
nom=E:\ORADATA\HERMES\DATA01.DBF
nom=E:\ORADATA\HERMES\INDX01.DBF
nom=E:\ORADATA\HERMES\DEFTBS01.DBF
canal ORA_DISK_1 : démarrage de l’élément 1 dans 05/08/08
canal ORA_DISK_1 : élément 1 terminé dans 05/08/08
descripteur d’élément=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\BACKUPSET\
2008_08_05\O1_MF_NNNDF_DBF_49HRPOC7_.BKP balise=DBF commentaire=NONE
canal ORA_DISK_1 : ensemble de sauvegarde terminé, temps écoulé : 00:00:55
Fin de backup dans 05/08/08
Démarrage de Control File and SPFILE Autobackup dans 05/08/08
descripteur d’élément=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\AUTOBACKUP\
2008_08_05\O1_MF_S_661936812_49HRRFXS_.BKP commentaire=NONE
Fin de Control File and SPFILE Autobackup dans 05/08/08
Dans le compte rendu d’une sauvegarde, nous trouvons les informations suivantes :
• les fichiers sauvegardés (par exemple "fichier de données en entrée …" pour une sauvegarde
de fichier de données) ;
• le nom complet du fichier de sauvegarde généré (par exemple "descripteur d’élément=" pour
un élément de sauvegarde) ;
24 | P a g e


• le fait qu’il y ait eu ou non une sauvegarde automatique du fichier de contrôle et du fichier de
paramètres serveur.
Les fichiers de données temporaires (fichiers de données des tablespaces temporaires gérés localement) ne
sont pas sauvegardés (c’est inutile).
2. Sauvegarde de la totalité de la base de données
Pour sauvegarder la totalité de la base, il suffit d’utiliser l’option DATABASE dans la commande
BACKUP :
BACKUP DATABASE ;
RMAN utilise les informations du fichier de contrôle de la base cible pour définir la liste des fichiers
de données à sauvegarder. En complément, il sauvegarde le fichier de contrôle et le fichier de
paramètres serveur (voir ci-après).
La commande BACKUP VALIDATE DATABASE peut être utilisée pour vérifier que la base de
données est en "bon état" (aucun fichier inaccessible, aucun fichier corrompu).
3. Sauvegarde de tablespaces ou de fichiers de données individuels
Pour sauvegarder individuellement quelques tablespaces ou quelques fichiers de données, vous

pouvez utiliser les options TABLESPACE et/ou DATAFILE dans la commande BACKUP.
Exemple :
BACKUP TABLESPACE data,indx ;

BACKUP DATAFILE 1,2,’E:\ORADATA\HERMES\DEFTBS01.DBF’ ;
BACKUP TABLESPACE system DATAFILE 5 ;
Les options TABLESPACE et DATAFILE peuvent être utilisées simultanément dans la même
commande. Un tablespace est désigné par son nom et un fichier de données par son numéro ou par son
nom. Lors de la sauvegarde d’un tablespace, RMAN utilise les informations du fichier de contrôle de
la base cible pour définir la liste des fichiers de données du tablespace et les sauvegarder.
4. Sauvegarde du fichier de contrôle et du fichier de paramètres serveur
Le fichier de contrôle et le fichier de paramètres serveur sont sauvegardés automatiquement dans deux
cas :
• Lorsque la sauvegarde automatique du fichier de contrôle a été activée.

• Lorsque le fichier de données numéro 1 (le premier fichier de données du tablespace
SYSTEM) est sauvegardé.
Dans les autres cas, le fichier de contrôle peut être explicitement sauvegardé en utilisant les options
CURRENT CONTROLFILE ou INCLUDE CURRENT CONTROLFILE dans la commande
BACKUP. De même, le fichier de paramètres serveur peut être explicitement sauvegardé en utilisant
l’option SPFILE.
25 | P a g e


Exemple :
BACKUP TABLESPACE data,indx INCLUDE CURRENT CONTROLFILE ;

BACKUP CURRENT CONTROLFILE ;
BACKUP AS COPY CURRENT CONTROLFILE ;BACKUP SPFILE ;
Si la sauvegarde automatique du fichier de contrôle a été activée, le fichier de contrôle ou le fichier de

paramètres serveur sont sauvegardés en double lorsqu’ils sont explicitement sauvegardés.
Le fichier de contrôle et le fichier de paramètres serveur sont sauvegardés dans un jeu de sauvegarde
séparé.
La sauvegarde automatique du fichier de contrôle est plus intéressante qu’une sauvegarde manuelle,
notamment car RMAN peut la restaurer automatiquement en cas de besoin (ce n’est pas le cas avec une
sauvegarde manuelle). De plus, dans cette configuration, le fichier de contrôle est automatiquement
sauvegardé lorsque la configuration des fichiers de la base de données change.
5. Sauvegarde des fichiers de journalisation archivés
Si les fichiers de journalisation ne sont pas archivés en double sur des disques séparés, ou ne sont pas
archivés dans la zone de récupération rapide (qui doit normalement être un disque séparé), il est
vivement conseillé de les sauvegarder ; ce sont eux en effet qui permettent de garantir une restauration
complète.
Les fichiers de journalisation archivés peuvent être sauvegardés en utilisant les options
ARCHIVELOG ou PLUS ARCHIVELOG dans la commande BACKUP.
Exemple :
BACKUP ARCHIVELOG ALL ;<$IRMAN;BACKUP ARCHIVELOG>

BACKUP ARCHIVELOG FROM TIME ’SYSDATE-1’ DELETE ALL INPUT ;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG FROM TIME ’SYSDATE-7’
NOT BACKED UP 2 TIMES ;
BACKUP DATABASE PLUS ARCHIVELOG ;
BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT ;
Dans les deux cas, si les fichiers de journalisation sont archivés vers plusieurs destinations, une seule
copie est sauvegardée pour chaque numéro de séquence de journalisation.
La commande BACKUP ARCHIVELOG cible permet de sauvegarder les fichiers de journalisation

désignés par la clause cible. La clause cible offre différentes possibilités parmi lesquelles :
ALL
Tous les fichiers de journalisation archivés. Ne peut pas être combinée avec d’autres options.
FROM TIME ’date’
Tous les fichiers de journalisation archivés depuis une certaine date.
UNTIL TIME ’date’
26 | P a g e


Tous les fichiers de journalisation archivés avant une certaine date.
TIME BETWEEN ’date1’ AND ’date2’
Tous les fichiers de journalisation archivés entre deux dates.
Si la commande inclut le fichier de journalisation le plus récent (option ALL ou absence d’option
UNTIL) et que la base de donnée est ouverte, RMAN commence par archiver tous les fichiers de
journalisation en ligne qui n’ont pas encore été archivés (et donc notamment le courant). De cette
manière, toute l’activité de journalisation générée avant le début de la commande est sauvegardée.
La commande BACKUP ... PLUS ARCHIVELOG permet de sauvegarder les fichiers de

journalisation en plus d’autres éléments (mais dans un jeu de sauvegarde séparé). Cette commande
effectue les opérations suivantes :
• archivage du fichier de journalisation courant ;

• sauvegarde de tous les fichiers de journalisation archivés (équivalent à la commande
BACKUP ARCHIVELOG ALL) ;
• sauvegarde des autres éléments ;
• de nouveau, archivage du fichier de journalisation courant ;
• sauvegarde des fichiers de journalisation archivés générés depuis le début de la sauvegarde.
De cette manière, toutes les sauvegardes de fichiers de données effectuées pendant l’opération (dans
un état incohérent) sont exploitables car tous les fichiers de journalisation nécessaires ont été
sauvegardés.
Utilisation de l’option NOT BACKED UP
L’option NOT BACKED UP peut être utilisée en plus, pour ne sauvegarder que les fichiers de
journalisation archivés qui n’ont pas déjà été sauvegardés un certain nombre de fois ou depuis un
certain temps.
Utilisation de l’option DELETE [ALL] INPUT
L’option DELETE [ALL] INPUT peut être utilisée pour supprimer les fichiers de journalisation
archivés qui viennent d’être sauvegardés.
Si les fichiers de journalisation sont archivés dans une seule destination, il n’y a pas de différence
entre l’option DELETE INPUT et l’option DELETE ALL INPUT.
Si les fichiers de journalisation sont archivés vers plusieurs destinations, il y a une différence entre les
deux options :
• DELETE INPUT supprime uniquement la copie du fichier de journalisation qui a été utilisé
pour la sauvegarde.
• DELETE ALL INPUT supprime toutes les copies du fichier de journalisation sauvegardé.
6. Sauvegarde incrémentale
Avec RMAN, il est possible de réaliser des sauvegardes incrémentales, de la totalité de la base de
données, de tablespaces individuels ou de fichiers de données individuels. L’objectif est de ne
sauvegarder que les blocs qui ont été modifiés depuis la dernière sauvegarde. Les sauvegardes
27 | P a g e


incrémentales présentent comme principal intérêt de réduire la taille des sauvegardes, notamment
lorsque l’activité de mise à jour est relativement faible sur la base de données.
Pour réaliser une sauvegarde incrémentale, il suffit d’inclure l’option INCREMENTAL LEVEL n
[CUMULATIVE] dans la commande BACKUP.
Exemple :
BACKUP INCREMENTAL LEVEL 0 DATABASE TAG=’dbinc0’ ;

BACKUP INCREMENTAL LEVEL 1 DATABASE TAG=’dbinc1’ ;
Une sauvegarde incrémentale peut être de niveau 0 ou de niveau 1, différentielle ou cumulative :
• Une sauvegarde incrémentale de niveau 0 sauvegarde toujours, tous les blocs utilisés des
fichiers de données. Elle est équivalente à une sauvegarde complète (mais une sauvegarde
complète n’est pas considérée par RMAN comme une sauvegarde incrémentale de niveau 0).
• Une sauvegarde incrémentale différentielle de niveau 1 sauvegarde tous les blocs modifiés
depuis la dernière sauvegarde incrémentale de niveau 0 ou 1. C’est le comportement par
défaut.
• Une sauvegarde incrémentale cumulative de niveau 1 sauvegarde tous les blocs modifiés
depuis la dernière sauvegarde incrémentale de niveau 0.
Les sauvegardes incrémentales cumulatives sont plus intéressantes pour la rapidité de récupération
(moins de sauvegardes intermédiaires à appliquer), mais nécessitent plus d’espace disque.
Lors d’une sauvegarde incrémentale de niveau 1, RMAN est obligé de lire tous les blocs utilisés pour
trouver ceux qui ont été modifiés et doivent donc être sauvegardés. En conséquence, la durée de la
sauvegarde n’est pas sensiblement réduite par rapport à une sauvegarde de niveau 0 (pas de gain sur la
lecture, simple gain sur l’écriture).
Si vous souhaitez réduire la durée de la sauvegarde, vous pouvez activer la fonctionnalité de trace des
blocs modifiés (block change tracking). Lorsque cette fonctionnalité est activée, Oracle garde une
trace des blocs modifiés dans un fichier. Lors d’une sauvegarde incrémentale de niveau 1, RMAN n’a
28 | P a g e


plus besoin de parcourir tous les blocs utilisés ; il emploie le fichier de trace des blocs modifiés pour
identifier les blocs à sauvegarder.
Pour activer la fonctionnalité de trace des blocs modifiés, vous pouvez utiliser l’ordre SQL suivant (ce
n’est pas une commande RMAN) :
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ’fichier’;
fichier donne le chemin complet et le nom du fichier de trace.
Exemple d’activation à partir de RMAN en utilisant la commande SQL :
RMAN> SQL "ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ’
’F:\oradata\HERMES\block_change_tracking.trc’’";
Il n’y a pas de recommandation particulière concernant l’emplacement du fichier ; vous pouvez le

placer dans l’environnement de la base de données ou dans la zone de récupération rapide.
Le fichier de trace des blocs modifiés n’est pas spécialement volumineux ; Oracle annonce une taille
de 1/30 000 de la taille de tous les blocs à tracer, indépendante de la fréquence de mise à jour. Le
fichier a une taille minimum de 10 Mo et grossit par pas de 10 Mo.
La vue V$BLOCK_CHANGE_TRACKING <donne des informations sur la trace des blocs modifiés :
SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES
---------- ------------------------------------------- ---------
ENABLED F:\ORADATA\HERMES\BLOCK_CHANGE_TRACKING.TRC 11599872
Si le fichier de trace est perdu ou endommagé, la base de données ne pourra pas être ouverte (elle
restera en état MOUNT). Pour ouvrir la base, il faut désactiver la trace, et éventuellement la réactiver
si vous souhaitez continuer à utiliser la fonctionnalité. Il n’existe pas de possibilité de sauvegarde et
de restauration du fichier de trace.
Pour déplacer le fichier de trace, vous pouvez utiliser l’ordre SQL ALTER DATABASE RENAME
FILE, base montée.
Pour désactiver la fonctionnalité de trace des blocs modifiés, vous pouvez utiliser l’ordre SQL
suivant :
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
Après activation de la trace, la première sauvegarde incrémentale de niveau 0 devra parcourir tous les
blocs utilisés car le fichier de trace ne reflète pas encore le statut des blocs. Il en est de même après
une recréation du fichier de trace.
Employer ou non un fichier de trace des blocs modifiés ne change rien aux commandes à utiliser pour
réaliser des sauvegardes incrémentales. Si la fonctionnalité est active, RMAN l’exploite ; sinon il s’en
passe.
Il existe une autre fonctionnalité intéressante concernant les sauvegardes incrémentales : la possibilité
de réaliser une sauvegarde sous forme de copie image et de mettre cette copie image à jour par
29 | P a g e


application régulière de sauvegardes incrémentales (Incrementally Updated Backup). Pour en savoir

plus, consultez la documentation Oracle® Database Backup and Recovery User’s Guide.
7. Exemples de scénario
a. Préambule
Les scénarios présentés ici s’appuient sur deux hypothèses :
• Une zone de récupération rapide est utilisée.

• La sauvegarde automatique des fichiers de contrôle a été activée.
b. Sauvegarde complète base fermée (cohérente)
Les commandes suivantes permettent de réaliser une sauvegarde complète base fermée (donc
cohérente) :
SHUTDOWN IMMEDIATE ; # arrêter la base

STARTUP MOUNT ; # monter la base
BACKUP DATABASE ; # sauvegarder la base
SQL "ALTER DATABASE OPEN" ; # ouvrir la base
Cette sauvegarde est un exemple typique de ce qui est fait lorsque la base fonctionne en mode
NOARCHIVELOG.
c. Sauvegarde complète base ouverte (incohérente)
La commande suivante permet de réaliser une sauvegarde complète base ouverte (donc incohérente),
avec sauvegarde des fichiers de journalisation archivés, et suppression des fichiers de journalisation
archivés sauvegardés :
BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;
Cette sauvegarde ne peut être effectuée que lorsque la base fonctionne en mode ARCHIVELOG.
d. Sauvegarde partielle base ouverte
Dans ce scénario, la totalité de la base est sauvegardée en trois fois sur trois jours :
• Sauvegarde 1 : fichiers de données 1 et 2
BACKUP DATAFILE 1,2 PLUS ARCHIVELOG DELETE ALL INPUT;
• Sauvegarde 2 : fichiers de données 3 et 4
BACKUP DATAFILE 3,4 PLUS ARCHIVELOG DELETE ALL INPUT;
• Sauvegarde 3 : le reste
BACKUP DATABASE NOT BACKED UP SINCE TIME=’SYSDATE-3’

PLUS ARCHIVELOG DELETE ALL INPUT;
30 | P a g e


Sur le principe, c’est une variante du scénario précédent. La commande pour la troisième sauvegarde
permet de sauvegarder tout ce qui n’a pas été sauvegardé depuis trois jours, y compris tout nouveau
fichier de données.
Il est techniquement possible de réaliser des sauvegardes partielles, base fermée, mais ces sauvegardes
ne sont exploitables que si la base de données fonctionne en mode ARCHIVELOG. Donc, autant les
réaliser base ouverte.
e. Sauvegarde incrémentale
Dans ce scénario, des sauvegardes incrémentales cumulatives sont réalisées sur un cycle d’une
semaine :
• Dimanche : sauvegarde incrémentale de niveau 0
BACKUP INCREMENTAL LEVEL 0 DATABASE ;
• Lundi au samedi : sauvegarde incrémentale cumulative de niveau 1
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE ;
Dans cet exemple, nous supposons que la base de données fonctionne en mode ARCHIVELOG, ce
qui nous permet de réaliser la sauvegarde base ouverte ; pour être tout à fait rigoureux, il faudrait en
plus s’occuper des fichiers de journalisation archivés (ajouter une clause PLUS ARCHIVELOG par
exemple).
Ce type de sauvegarde peut aussi être réalisé si la base de données fonctionne en mode
NOARCHIVELOG, en ajoutant les commandes suivantes :
SHUTDOWN IMMEDIATE ; # arrêter la base

STARTUP MOUNT ; # monter la base
BACKUP INCREMENTAL... ; # sauvegarder la base ici
SQL "ALTER DATABASE OPEN" ; # ouvrir la base
Le référentiel RMAN
1. Trouver des informations sur les sauvegardes
a. La commande LIST
La commande LIST permet d’interroger le référentiel RMAN pour afficher des informations sur les
sauvegardes et les fichiers de journalisation archivés.
Syntaxe 1
LIST cible [ BY FILE | SUMMARY ] [ filtre_sauvegarde ];

- cible
{ BACKUP | COPY } [ OF objets ]
BACKUPSET
- objets
DATABASE
31 | P a g e


CONTROLFILE
SPFILE
ARCHIVELOG { ALL | filtre_archive }
- filtre_archive
- filtre_sauvegarde
TAG [=] ’nom’
COMPLETED { AFTER ’date1’
| BEFORE ’date2’
| BETWEEN ’date1’ AND ’date2’ }
Syntaxe 2
LIST { BACKUPSET | BACKUPPIECE } { liste_clés | TAG [=] ’nom’ };
Syntaxe 3
LIST ARCHIVELOG { ALL | filtre_archive } [info_sauvegarde];

- info_sauvegarde
BACKED UP n TIMES TO DEVICE TYPE [DISK | ’media’]

Toutes les options possibles ne sont pas présentées ici.
Première syntaxe
La première syntaxe permet d’afficher des informations sur les sauvegardes enregistrées dans le
référentiel RMAN.
Par défaut, les commandes LIST BACKUP, LIST COPY et LIST BACKUPSET listent tous les
éléments enregistrés dans le référentiel RMAN.
Dans le cas des commandes LIST BACKUP et LIST COPY, il est possible de spécifier un ou
plusieurs objets pour n’afficher que les sauvegardes des objets en question.
Exemple :
LIST BACKUP OF DATABASE ; # n’importe quel fichier de la base

LIST BACKUP OF DATAFILE 1,’E:\ORADATA\HERMES\DATA01.DBF’ ;
LIST BACKUP OF TABLESPACE system,sysaux ;
LIST BACKUP OF CONTROLFILE SPFILE ;
LIST BACKUP OF ARCHIVELOG ALL ;
LIST BACKUP OF ARCHIVELOG UNTIL TIME ’SYSDATE-1’ ;
Le dernier exemple liste les sauvegardes des fichiers de journalisation archivés il y a plus d’un jour,
quelle que soit la date de la sauvegarde (peut dater de moins d’un jour) ; il ne faut pas confondre le
filtre de date d’archivage (option filtre_archive) et le filtre de date de sauvegarde (option
filtre_sauvegarde).
L’option filtre_sauvegarde permet de filtrer la liste grâce à un critère portant sur la sauvegarde : date
de la sauvegarde et/ou nom associé à la sauvegarde (option TAG de la commande BACKUP).
Exemple :
32 | P a g e


LIST BACKUP TAG=’DBINC0’ ;

LIST BACKUP COMPLETED AFTER ’SYSDATE-1’ ;
LIST BACKUP TAG=’DBINC0’ COMPLETED AFTER ’SYSDATE-1’ ;
LIST BACKUP OF ARCHIVELOG UNTIL TIME ’SYSDATE-1’
COMPLETED AFTER ’SYSDATE-1’ ;
Le dernier exemple liste les sauvegardes des fichiers de journalisation archivés il y a plus d’un jour
mais sauvegardés il y a moins d’un jour.
Les commandes LIST BACKUP OF et LIST BACKUPSET listent les sauvegardes par jeu de
sauvegarde, avec un affichage détaillé donnant le contenu de chaque sauvegarde.
Exemple (extrait)
RMAN> LIST BACKUP OF DATABASE;
Liste des ensembles de sauvegarde

===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ---------------
17 Full 75.78M DISK 00:00:45 05/08/08
BP Key: 17 Status: AVAILABLE Compressed: YES Tag:
TAG20080805T080633
Piece Name: H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\BACKUPSET\
2008_08_05\O1_MF_NNNDF_TAG20080805T080633_49HVH9KL_.BKP
Liste des fichiers de données dans l’ensemble de sauvegarde 17
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- -------- ----
1 Full 410531 05/08/08 E:\ORADATA\HERMES\SYSTEM01.DBF
2 Full 410531 05/08/08 E:\ORADATA\HERMES\SYSAUX01.DBF
3 Full 410531 05/08/08 E:\ORADATA\HERMES\UNDOTBS01.DBF
4 Full 410531 05/08/08 E:\ORADATA\HERMES\DEFTBS01.DBF
5 Full 410531 05/08/08 E:\ORADATA\HERMES\DATA01.DBF
6 Full 410531 05/08/08 E:\ORADATA\HERMES\INDX01.DBF
La colonne "Clé BS" donne le numéro (clé) attribué par RMAN au jeu de sauvegarde.
L’option SUMMARY permet d’obtenir un affichage résumé (pas de détail sur le contenu des
sauvegardes), organisé par jeu de sauvegarde.
L’option BY FILE permet d’obtenir un affichage résumé, organisé par fichier sauvegardé.
Deuxième syntaxe
La deuxième syntaxe permet d’afficher des informations sur des jeux de sauvegarde (BACKUPSET)
ou éléments de sauvegarde (BACKUPPIECE) précis (soit par une liste de clés, soit par le nom associé
à la sauvegarde grâce à l’option TAG de la commande BACKUP).
Exemples
LIST BACKUPSET 8;
LIST BACKUPSET TAG=’DBINC0’ ;
LIST BACKUPPIECE 76 ;
33 | P a g e


La clé d’un élément de sauvegarde ("Clé BP") n’est pas forcément égale à la clé du jeu de sauvegarde
("Clé BS"), car un jeu de sauvegarde peut avoir plusieurs éléments de sauvegarde, ce qui génère un
décalage dans la numérotation.
Troisième syntaxe
La troisième syntaxe permet d’afficher des informations sur les fichiers de journalisation archivés
considérés comme disponibles par RMAN, c’est-à-dire non supprimés par RMAN (avec l’option
DELETE INPUT).
Exemples
LIST ARCHIVELOG ALL ; # tous

LIST ARCHIVELOG FROM TIME ’SYSDATE-1/24’ ; # dans la dernière heure
LIST ARCHIVELOG ALL BACKED UP 2 TIMES
TO DEVICE TYPE DISK ; # archives sauvegardées 2 fois sur disque
LIST ARCHIVELOG ALL BACKED UP 0 TIMES
TO DEVICE TYPE DISK ; # archives jamais sauvegardées sur disque
b. La commande REPORT
La commande REPORT permet de réaliser des interrogations plus évoluées sur le référentiel RMAN.
Il existe trois utilisations principales de la commande REPORT :
• lister les éléments qui nécessitent une sauvegarde ;

• lister les sauvegardes obsolètes ;
• afficher la liste des fichiers de données de la base de données.
Lister les éléments qui nécessitent une sauvegarde
Syntaxe
REPORT NEED BACKUP [condition] [objets];<$IRMAN;REPORT NEED BACKUP>

- condition
DAYS [=] n
INCREMENTAL [=] n
RECOVERY WINDOW OF n DAYS
REDUNDANCY [=] n
- objets
DATABASE
Par défaut, la commande REPORT NEED BACKUP affiche la liste des fichiers qui nécessitent une
sauvegarde, en tenant compte de la politique de conservation configurée (CONFIGURE RETENTION
POLICY).
L’option condition permet de préciser le critère que la commande REPORT doit utiliser pour
déterminer si un fichier a besoin d’être sauvegardé. Les conditions possibles sont :
DAYS [=] n
Fichiers de données qui nécessitent plus de n jours d’application de fichiers de journalisation archivés
pour être récupérés en cas d’incident.
34 | P a g e


INCREMENTAL [=] n
Fichiers de données qui nécessitent plus de n applications de sauvegardes incrémentales pour être
récupérés en cas d’incident.
Une fenêtre de récupération particulière (même syntaxe que dans la commande CONFIGURE
RETENTION POLICY).
REDUNDANCY [=] n
Une redondance particulière (même syntaxe que dans la commande CONFIGURE RETENTION
POLICY).
L’option objets permet de s’intéresser à des tablespaces ou des fichiers de données précis.
Avant d’exécuter cette commande, il peut être utile d’exécuter la commande CROSSCHECK (voir plus loin)
pour mettre à jour le statut des sauvegardes dans le référentiel RMAN.
Lister les sauvegardes obsolètes
Syntaxe
REPORT OBSOLETE [condition];

- condition
REDUNDANCY [=] n
Par défaut, la commande REPORT OBSOLETE affiche les sauvegardes obsolètes en tenant compte
de la politique de conservation configurée (CONFIGURE RETENTION POLICY).
L’option condition permet de préciser le critère que la commande REPORT doit utiliser pour
déterminer si une sauvegarde est obsolète. La syntaxe est la même que dans la commande
CONFIGURE RETENTION POLICY.
Avant d’exécuter cette commande, il peut être utile d’exécuter la commande CROSSCHECK (voir plus loin)
pour mettre à jour le statut des sauvegardes dans le référentiel RMAN.
Afficher la liste des fichiers de données de la base de données
Syntaxe
REPORT SCHEMA ;
35 | P a g e


2. Gérer le référentiel RMAN
a. La commande CROSSCHECK
La commande CROSSCHECK permet de vérifier que les informations enregistrées dans le référentiel
RMAN correspondent bien à des fichiers qui existent physiquement. Un décalage peut se produire si
un fichier est directement supprimé au niveau du système d’exploitation. La commande
CROSSCHECK met à jour le statut de l’élément dans le référentiel RMAN mais ne supprime rien (ni
fichier physique, ni enregistrement dans le référentiel).
Les statuts possibles sont les suivants :
EXPIRED
L’objet n’a pas été trouvé au niveau du système d’exploitation.
AVAILABLE
L’objet est disponible et peut être utilisé par RMAN.
UNAVAILABLE
L’objet n’est pas disponible et ne peut pas être utilisé par RMAN (suite à l’utilisation de la commande
CHANGE ... UNAVAILABLE - voir la documentation Oracle).
Un enregistrement qui a été marqué EXPIRED lors d’un CROSSCHECK peut repasser AVAILABLE
lors d’un nouveau CROSSCHECK s’il n’a été que temporairement inaccessible. Vous pouvez aussi
utiliser la commande CHANGE ... AVAILABLE pour remettre le statut AVAILABLE à un
enregistrement si le fichier physique est de nouveau accessible (voir la documentation Oracle).
Syntaxe 1
CROSSCHECK cible [ filtre_sauvegarde ] ;

- cible
BACKUPSET
- objets
DATABASE
CONTROLFILE
SPFILE
Syntaxe 2
CROSSCHECK { BACKUPSET | BACKUPPIECE } { liste_clés | TAG [=] ’nom’ };
Syntaxe 3
CROSSCHECK ARCHIVELOG { ALL | filtre_archive };

Toutes les options possibles ne sont pas présentées ici.
36 | P a g e


Les variantes de syntaxe et options sont les mêmes que pour la commande LIST.Le statut est affiché
dans le résultat de la commande LIST. La commande LIST EXPIRED, variante de la commande
LIST, permet de lister les éléments qui ont le statut EXPIRED.
Exemple 1
RMAN> CROSSCHECK BACKUP ;

élément de sauvegarde vérifié : repéré comme étant ’EXPIRED’
descripteur d’élément de sauvegarde=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
BACKUPSET\2008_08_05\O1_MF_NNNDF_TAG20080805T080633_49HVH9KL_.BKP RECID=17
STAMP=661939593
élément de sauvegarde vérifié : repéré comme étant ’AVAILABLE’
descripteur d’élément de sauvegarde=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
AUTOBACKUP\2008_08_05\O1_MF_S_661939648_49HVK1Z7_.BKP RECID=18 STAMP=661939649
2 objets contre-vérifiés
RMAN> LIST EXPIRED BACKUP ;

Liste des ensembles de sauvegarde
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
17 Full 75.78M DISK 00:00:45 05/08/08
BP Key: 17 Status: EXPIRED
Compressed: YES Tag: TAG20080805T080633
Piece Name: H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\BACKUPSET\
2008_08_05\O1_MF_NNNDF_TAG20080805T080633_49HVH9KL_.BKP
...
Exemple 2
RMAN> CROSSCHECK ARCHIVELOG ALL ;

canal libéré : ORA_DISK_1
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : SID=186 type d’unité=DISK
échec de la validation du journal d’archivage
nom de journal d’archivage=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
ARCHIVELOG\2008_08_05\O1_MF_1_40_49HWKM2G_.ARC RECID=12 STAMP=661940692
validation réussie du journal d’archivage
nom de journal d’archivage=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
ARCHIVELOG\2008_08_05\O1_MF_1_41_49HWKN89_.ARC RECID=14 STAMP=661940692
...
RMAN> LIST EXPIRED ARCHIVELOG ALL ;

Liste des copies des journaux d’archivage dont le nom est db_unique_name
HERMES
========================================================================
Key Thrd Seq S Low Time
------- ---- ------- - --------
12 1 40 X 05/08/08
Name: H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\ARCHIVELOG\
2008_08_05\O1_MF_1_40_49HWKM2G_.ARC
b. La commande DELETE
La commande DELETE peut être utilisée pour supprimer des sauvegardes. Elle supprime les fichiers
physiques et l’enregistrement dans le référentiel RMAN.
La commande DELETE propose deux variantes principales pour :
37 | P a g e


• supprimer des sauvegardes ou des fichiers de journalisation spécifiques ;

• supprimer les sauvegardes obsolètes.
Supprimer des sauvegardes ou des fichiers de journalisation spécifiques
Syntaxe 1
DELETE [FORCE] [NOPROMPT] [EXPIRED] cible [ filtre_sauvegarde ] ;

- cible
BACKUPSET
- objets
DATABASE
CONTROLFILE
SPFILE
- filtre_archive
- filtre_sauvegarde
TAG [=] ’nom’
COMPLETED { AFTER ’date1’
| BEFORE ’date2’
| BETWEEN ’date1’ AND ’date2’ }
Syntaxe 2
DELETE [FORCE] [NOPROMPT] [EXPIRED] { BACKUPSET | BACKUPPIECE }

{ liste_clés | TAG [=] ’nom’ };
Syntaxe 3
DELETE [FORCE] [NOPROMPT] [EXPIRED] ARCHIVELOG { ALL | filtre_archive }

[info_sauvegarde];
- info_sauvegarde
BACKED UP n TIMES TO DEVICE TYPE [DISK | ’media’]
Les variantes de syntaxe et options sont les mêmes que pour la commande LIST.
L’option EXPIRED permet de supprimer les éléments marqués EXPIRED dans le référentiel RMAN
(éventuellement, combinée à d’autres critères).
Par défaut, RMAN liste les fichiers qu’il s’apprête à supprimer et demande confirmation de la
suppression. L’option NOPROMPT permet de supprimer la demande de confirmation (mais la liste
des fichiers supprimés est toujours affichée).
La commande DELETE génère une erreur s’il n’existe pas de concordance entre le référentiel et les
fichiers physiques :
• Un fichier est marqué EXPIRED dans le référentiel mais existe physiquement.

• Un fichier est marqué AVAILABLE dans le référentiel mais n’existe pas physiquement.
Pour résoudre ce problème, vous pouvez au choix :
38 | P a g e


• exécuter la commande CROSSCHECK pour mettre à jour le statut des fichiers dans le
référentiel ;
• utiliser l’option FORCE de la commande DELETE ;
• utiliser la commande CHANGE ... UNCATALOG pour supprimer du référentiel une référence
à un fichier qui n’existe plus (voir la documentation Oracle).
Réfléchissez bien avant de supprimer quoi que ce soit.
Exemples d’appel
# supprimer les sauvegardes ayant un certain nom

DELETE BACKUP OF DATABASE TAG=’DBINC0’ ;
# supprimer les sauvegardes du fichier de paramètres serveur
# réalisées il y a plus de 7 jours
DELETE NOPROMPT BACKUP OF SPFILE COMPLETED BEFORE ’SYSDATE-7’ ;
# supprimer toutes les sauvegardes marquées EXPIRED
DELETE EXPIRED BACKUP ;
# supprimer tous les fichiers de journalisation archivés générés
# il y plus d’un jour et sauvegardé trois fois sur disque
DELETE ARCHIVELOG UNTIL TIME ’SYSDATE-1’ BACKED UP 3 TIMES TO DISK ;
Supprimer les sauvegardes obsolètes
Syntaxe 2
DELETE [FORCE] [NOPROMPT] OBSOLETE [ condition ] ;

- condition
REDUNDANCY [=] n
Lorsque la commande est appelée sans option, RMAN supprime les sauvegardes obsolètes en tenant
compte de la politique de conservation configurée (CONFIGURE RETENTION POLICY).
L’option condition permet de préciser le critère que la commande DELETE doit utiliser pour
déterminer si une sauvegarde est obsolète. La syntaxe est la même que dans la commande
CONFIGURE RETENTION POLICY.
Si vous utilisez une zone de récupération rapide, RMAN supprimera automatiquement les sauvegardes
obsolètes (compte tenu de la politique de conservation configurée), mais uniquement s’il manque de
place.
c. La commande CATALOG
La commande CATALOG permet d’indiquer à RMAN l’existence de fichiers de journalisation

archivés ou d’éléments de sauvegarde qui ne sont pas enregistrés dans le référentiel RMAN.
Cette situation peut se produire dans plusieurs cas :
• Vous avez utilisé la commande DELETE à mauvais escient et vous avez toujours le fichier
physique.
• Vous avez effectué une récupération avec une sauvegarde du fichier de contrôle, qui ne
contient donc pas les informations sur ce qui a été fait avec RMAN depuis la sauvegarde en
question.
39 | P a g e


• Vous avez recréé le fichier de contrôle (il ne contient plus rien).

• Un enregistrement a été supprimé du fichier de contrôle du fait de la valeur du paramètre
CONTROL_FILE_RECORD_KEEP_TIME, mais le fichier physique existe toujours et vous
en avez besoin pour une récupération.
• Vous avez déplacé un fichier physique.
Syntaxe
CATALOG { ARCHIVELOG | BACKUPPIECE } liste_fichiers ;

CATALOG { RECOVERY AREA | DB_RECOVERY_FILE_DEST } [NOPROMPT] ;
CATALOG START WITH ’chemin’ [NOPROMPT] ;
La première syntaxe permet de cataloguer des fichiers précis. Si vous cataloguez un élément déjà
catalogué, RMAN supprime l’ancienne référence avant de créer la nouvelle.
La deuxième syntaxe permet de cataloguer tous les fichiers stockés dans la zone de récupération
rapide (RECOVERY AREA et DB_RECOVERY_FILE_DEST sont synonymes).
La troisième syntaxe permet de cataloguer tous les fichiers dont le nom complet commence par une
certaine chaîne de caractères (ne peut pas contenir de caractères joker).
Avec les deux dernières syntaxes, RMAN demande confirmation avant de cataloguer un
fichier ; l’option NOPROMPT permet de supprimer la demande de confirmation. Par ailleurs, RMAN
ne catalogue pas les fichiers déjà catalogués.
Récupération
1. Vue d’ensemble
La stratégie de récupération dépend de plusieurs facteurs :
• De la nature du(des) fichier(s) endommagé(s) ou perdu(s) :

o fichier de données ;
o fichier de contrôle ;
o fichier de paramètres serveur ;
o fichier de journalisation.
• Du mode de fonctionnement de la base :
o ARCHIVELOG
o NOARCHIVELOG.
• Des sauvegardes disponibles.
Que faire en cas de problème ?
1. identifier la nature du problème ;
2. définir le mode opératoire en tenant compte du mode de fonctionnement de la base et des

sauvegardes disponibles.
Surtout, ne vous précipitez pas et n’hésitez pas à vous faire aider par le support Oracle.
40 | P a g e


Depuis la version 11, Oracle propose un conseiller pour la récupération des données (le Data
Recovery Advisor) qui permet de diagnostiquer et résoudre facilement les incidents (perte ou
corruption) des données sur disque. Ce nouvel outil est présenté dans la section Data Recovery
Advisor.
Dans la suite du document, les termes "perdu" et "endommagé" seront indifféremment utilisés pour
désigner l’incident ; dans la pratique, que le fichier soit perdu ou simplement endommagé, les
procédures de restauration sont les mêmes.
Une opération de récupération s’effectue essentiellement avec RMAN. Pour certaines étapes,
SQL*Plus peut être nécessaire, essentiellement pour interroger quelques vues du dictionnaire de
données ; une connexion AS SYSDBA sera nécessaire si la base n’est pas ouverte.
Un conseil, avant de commencer toute opération de récupération, réalisez si possible une sauvegarde
complète de la base endommagée. Cela peut fournir un point de retour en cas d’aggravation de la situation
par une mauvaise manipulation. Au minimum, réalisez une sauvegarde du fichier de contrôle et des fichiers
de journalisation en ligne (par simple copie au niveau du système d’exploitation).
Dans une opération de "restauration" ou de "récupération", il existe en fait deux étapes bien précises et
bien distinctes :
1. L’étape de restauration (restore) consiste à extraire d’une sauvegarde les fichiers nécessaires.
2. L’étape de récupération (recover) consiste à appliquer les fichiers de journalisation aux fichiers
récupérés de la sauvegarde.
Pour être rigoureux, il faudrait donc évoquer une opération de "restauration et récupération".
2. Principes généraux de la récupération
a. En mode NOARCHIVELOG
En mode NOARCHIVELOG, le mode opératoire est on ne peut plus simple :
• restaurer la dernière sauvegarde complète de la base ;

• redémarrer la base.
Toutes les modifications apportées depuis la dernière sauvegarde sont perdues.
A priori, la restauration en mode NOARCHIVELOG ne permet pas de ramener la base de données à

l’état où elle se trouvait juste avant l’incident ; elle permet juste de ramener la base de données à l’état
où elle se trouvait au moment de la sauvegarde.
Néanmoins, dans certaines situations, il peut être possible de récupérer tout ou partie des
modifications apportées depuis la dernière sauvegarde.
L’objectif des indications données ci‐après est de montrer que tout n’est pas forcément perdu. En cas de
problème en mode NOARCHIVELOG, il ne faut pas hésiter à appeler le support Oracle pour tenter avec eux de
réaliser la récupération la plus complète possible. Par contre, pour être certain de garantir une récupération
41 | P a g e


complète dans toutes les situations (et simplifier le processus de récupération), il faut faire fonctionner la
base en mode ARCHIVELOG.
Les situations sont les suivantes :
• Un cycle complet de basculement des fichiers de journalisation n’a pas eu lieu depuis la
sauvegarde.
• Le fichier de données perdu n’est pas critique pour la base de données (n’appartient pas au
tablespace SYSTEM, ni à au tablespace d’annulation actif), ni pour l’application (ce n’est pas
le tablespace principal de l’application).
• Tous les fichiers de contrôle sont perdus mais les autres fichiers (données et journalisation)
sont intacts.
Si les fichiers de journalisation n’ont pas subi un cycle complet de basculements depuis la sauvegarde
utilisée, toutes les mises à jour effectuées depuis la sauvegarde en question sont encore "disponibles"
dans les fichiers de journalisation. Dans ce cas, il faut réaliser une récupération comme si la base de
données était en mode ARCHIVELOG (voir les scénarios correspondants).
Si le fichier de données perdu n’est pas critique pour la base de données ni pour l’application, et que
le problème soit survenu alors que la base de données était arrêtée, la situation est plutôt favorable car
les fichiers qui restent sont cohérents entre eux : si ce problème de fichier n’existait pas, le prochain
démarrage ne nécessiterait pas de récupération de l’instance.
Dans ce cas, il est possible :
• De démarrer la base de données en état MOUNT
SQL> CONNECT / AS SYSDBA

SQL> STARTUP MOUNT
• De mettre les fichiers de donnés concernés OFFLINE avec l’option DROP
SQL> ALTER DATABASE DATAFILE

2 ’e:\oradata\HERMES\indx01.dbf’ OFFLINE DROP;
• D’ouvrir la base de données
• De supprimer le tablespace
SQL> DROP TABLESPACE indx;
• Puis de recréer le tablespace (et éventuellement son contenu)
SQL> CREATE TABLESPACE indx ... ;

SQL> CREATE INDEX ... ;
À l’arrivée, le tablespace est supprimé : cette technique n’est donc pas applicable si le fichier de
données perdu est critique pour la base de données ou pour l’application. Elle est, par contre,
envisageable pour des tablespaces contenant uniquement des index (les données, elles, ne sont pas
perdues).
42 | P a g e


Si le problème est survenu alors que la base était en fonctionnement, la situation est plus
problématique car les fichiers de données restants ne sont peut-être pas cohérents et il n’existe pas
vraiment de moyens de le savoir.
S’ils ne sont pas cohérents, Oracle aura besoin des fichiers de journalisation en ligne pour les rendre
cohérents (c’est la récupération de l’instance "classique"). Si les fichiers de journalisation sont
présents, ou si seuls les fichiers de journalisation INACTIVE sont perdus, la technique présentée
précédemment pourra être utilisée ; si les fichiers de journalisation CURRENT ou ACTIVE sont
perdus, la technique ne pourra pas être employée (il faut repartir de la dernière sauvegarde).
Tous les fichiers de contrôle sont perdus. Dans cette situation critique et délicate, pour laquelle il
existe différentes possibilités de récupération, la documentation Oracle recommande de contacter le
support Oracle.
b. En mode ARCHIVELOG
En mode ARCHIVELOG, le mode opératoire de base pour une perte de fichier(s) de données est le
suivant :
• restaurer la dernière sauvegarde de chaque fichier perdu ;

• appliquer les fichiers de journalisation (archives puis ceux en ligne) ;
• redémarrer la base (si la récupération n’a pas été faite base ouverte).
Toutes les modifications apportées depuis les sauvegardes utilisées sont récupérées. La récupération
est dite complète.
Ce type de récupération est simple et ne pose pas de problème s’il reste au moins un fichier de
contrôle, un membre par groupe de fichier de journalisation et que toutes les archives de fichiers de
journalisation sont disponibles.
Sur la base de ce scénario, différentes situations peuvent conduire à une récupération incomplète :
• volontairement, pour s’arrêter avant un ordre SQL malencontreux ;

• involontairement, si des fichiers de journalisation sont perdus (une archive ou tout un groupe
de fichiers de journalisation en ligne).
Dans la terminologie Oracle, une récupération incomplète est appelée point-in-time recovery.
Si tous les fichiers de contrôle sont perdus, si tout un groupe de fichiers de journalisation est perdu, ou
s’il manque une archive de fichiers de journalisation, la récupération complète sera plus délicate et
dans certains cas impossible (par exemple, s’il manque une archive de fichier de journalisation) ; une
récupération incomplète reste alors possible et la base n’est pas ramenée à l’état où elle se trouvait
juste avant l’incident mais à un état antérieur.
Dans certaines situations (suppression de table malencontreuse par exemple), la récupération

incomplète peut être volontaire ; là encore, la base de données n’est pas ramenée à l’état où elle se
trouvait juste avant l’incident mais à un état antérieur.
Quelle que soit l’origine de la récupération incomplète, tout ce qui a été fait, après le moment qui
correspond à l’état de récupération de la base, est perdu et doit être repris à la main : dans une
séquence d’application des fichiers de journalisation, Oracle ne peut pas "sauter" quelques ordres puis
continuer.
43 | P a g e


Lors de la restauration des sauvegardes, si les sauvegardes sont partielles, il faut prendre la sauvegarde
la plus récente de chaque fichier endommagé.
3. Les incidents sur les fichiers de contrôle et de journalisation
Les incidents sur les fichiers de contrôle et les fichiers de journalisation peuvent être classés en deux
catégories : "peu graves" et "très graves".
Incidents peu graves :
• perte d’un ou plusieurs fichiers de contrôle, du moment qu’il en reste au moins un ;

• perte d’un ou plusieurs fichiers de journalisation, du moment qu’il en reste au moins un par
groupe.
Incidents plus graves et plus complexes à traiter :
• perte de tous les fichiers de contrôle : moyennement grave si les autres fichiers sont intacts ;
• perte de tous les membres d’un groupe de fichiers de journalisation : la gravité dépend du
statut du groupe perdu (CURRENT, ACTIVE, INACTIVE).
Ces situations sont évitées si l’on multiplexe correctement les fichiers de contrôle et les fichiers de
journalisation. La perte de tous les fichiers de contrôle n’est pas la situation la plus complexe à traiter,
s’il existe des sauvegardes récentes du fichier de contrôle et si les autres fichiers (particulièrement, les
fichiers de journalisation) sont intacts ; dans ce cas, une récupération complète est possible.
La perte de tous les membres d’un groupe de fichiers de journalisation est bien plus complexe à
traiter ; la situation de départ doit être analysée avec soin (statut du groupe perdu, état des autres
fichiers, etc.), afin de choisir le bon mode opératoire. Pour les situations complexes, il est vivement
conseillé de se faire aider par le support Oracle.
4. Identifier la nature du problème
a. Message d’erreur concernant les fichiers de contrôle
Les messages d’erreurs les plus fréquents sur les fichiers de contrôle sont les suivants :
ORA-00204: erreur lors de la lecture (bloc, nbre blocs)

du fichier de contrôle
ORA-00205: erreur lors de l’identification du fichier
de contrôle; consultez le journal des alertes
ORA-00206: erreur lors de l’écriture (bloc, nbre blocs)
du fichier de contrôle
Ces messages indiquent qu’au moins un fichier de contrôle est endommagé ou perdu ; il faut consulter
le fichier des alertes de l’instance pour en savoir plus, notamment pour déterminer les fichiers
endommagés et en déduire les fichiers intacts, s’il en reste. En cas de problème sur un fichier de
contrôle, l’instance s’arrête. Au redémarrage, l’instance reste en état NOMOUNT.
b. Message d’erreur concernant les fichiers de journalisation
Les messages d’erreur les plus fréquents sur les fichiers de journalisation sont les suivants :
ORA-00313: échec d’ouverture des membres du groupe de journaux n, thread p
44 | P a g e


ORA-00315: journal n, thread p, numéro de thread x incorrect

dans en-tête
ORA-00316: le journal n dans le thread p, type x dans l’en-tête,
n’est pas un fichier journal
ORA-00317: le type de fichier x dans l’en-tête n’est pas un fichier journal
ORA-00318: journal n, thread p, taille x de fich. attendue
ne correspond pas à y
ORA-00319: journal n du thread p a un état de réinitialisation incorrect
ORA-00320: impossible lire en-tête de fichier du journal n thread p
ORA-00321: fichier n, thread p, impossible de mettre à jour l’en-tête
du fichier journal
Ces messages s’accompagnent d’un ou plusieurs messages ORA-00312 donnant le nom du fichier :
ORA-00312: journal en ligne n thread p : fichier
En cas de problème sur tout un groupe de fichiers de journalisation, l’instance s’arrête. Au

redémarrage, l’instance reste en état MOUNT.
En cas de problème, il faut consulter le fichier d’alerte de l’instance et le fichier de trace du processus
LGWR.
c. Message d’erreur concernant les fichiers de données
Il y a de nombreux messages d’erreur possibles concernant les fichiers de données, par exemple :
ORA-01157: impossible d’identifier ou de verrouiller le fichier

de données n - voir le fichier de trace DBWR
Ces messages s’accompagnent d’un ou plusieurs messages ORA-01110 donnant le nom du fichier :
ORA-01110: fichier de données n : fichier
En mode NOARCHIVELOG, si la base de données est ouverte et qu’un problème se produise sur un
fichier de données, l’instance s’arrête. En mode ARCHIVELOG, il en est de même mais uniquement
si le fichier de données incriminé est un fichier du tablespace SYSTEM ou un fichier de données du
tablespace d’annulation actif.
Au démarrage, l’instance reste en état MOUNT.
En cas de problème, il faut consulter le fichier d’alerte de l’instance et le fichier de trace du processus
DBWR. D’autres fichiers, eux aussi endommagés, peuvent être cités.
Lorsque la base de données est montée ou ouverte, vous pouvez interroger la vue
V$RECOVER_FILE pour déterminer la liste des fichiers de données sur lesquels il existe un
problème.
Les colonnes intéressantes de la vue V$RECOVER_FILE sont les suivantes :
FILE#
Identifiant du fichier (jointure sur V$DATAFILE.FILE# pour récupérer des informations

complémentaires sur le fichier).
ONLINE_STATUS
45 | P a g e


Statut du fichier (ONLINE ou OFFLINE).
ERROR
Nature de l’erreur. Vide si l’erreur est inconnue et OFFLINE NORMAL si le fichier est hors ligne
sans erreur (pas besoin de restauration dans ce cas).
Exemple
SQL> SELECT file#,error,online_status FROM v$recover_file;

FILE# ERROR ONLINE_
---------- ------------------------------ -------
5 FILE NOT FOUND ONLINE
Sur cet exemple, le fichier de données 5 doit être restauré.
La commande VALIDATE DATABASE peut aussi être utilisée pour identifer les fichiers de données
perdus ou endommagés.
5. Les commandes RMAN
a. Introduction
Dans RMAN, les opérations de restauration et de récupération vont s’effectuer respectivement avec
les commandes RESTORE et RECOVER.
La commande RESTORE permet de restaurer les fichiers à partir des sauvegardes. La commande
RECOVER permet de procéder à une récupération complète ou incomplète.
La syntaxe générale de ces deux commandes est du type :
{ RESTORE | RECOVER } cible [options] ;
Votre principale responsabilité, lorsque vous utilisez ces commandes, est de bien choisir la cible en
fonction de la nature du problème. Ensuite, RMAN se charge normalement de tout : identifier les
sauvegardes à utiliser, et en extraire les fichiers requis ; identifier les fichiers de journalisation
archivés nécessaires et les extraire d’une sauvegarde s’ils ont été sauvegardés puis supprimés.
Les options de ces deux commandes ne seront nécessaires que pour traiter des cas
particuliers : sauvegarde non disponible, volonté de revenir à un instant dans le passé (récupération
incomplète), etc. Dans la grande majorité des cas, vous ne devriez pas en avoir besoin.
Les principes de fonctionnement généraux de ces commandes vont d’abord être présentés, puis nous
verrons comment les utiliser dans différents scénarios de restauration.
Les commandes RESTORE et RECOVER proposent un très grand nombre d’options. Dans cet ouvrage, nous
présenterons uniquement les options les plus couramment utilisées.
b. La commande RESTORE
La syntaxe simplifiée de la commande RESTORE est la suivante :
46 | P a g e


RESTORE cibles [options]

- cibles
DATABASE
CONTROLFILE [TO ’destination’] [FROM AUTOBACKUP | ’sauvegarde’]
SPFILE [TO ’destination’] [FROM AUTOBACKUP | ’sauvegarde’]
- filtre_archive
- options
PREVIEW [SUMMARY]
VALIDATE
L’option cibles permet d’indiquer ce qu’il convient de restaurer. L’option DATABASE permet de
restaurer la totalité de la base de données ; elle ne doit être utilisée que si vous souhaitez ou devez
effectivement restaurer la totalité de la base de données. En mode ARCHIVELOG, si un fichier de
données est endommagé, vous ne devrez restaurer que le fichier en question, en utilisant les options
DATAFILE ou TABLESPACE.
L’option PREVIEW est intéressante pour lister les sauvegardes dont RMAN a besoin pour réaliser
l’opération de restauration correspondante. L’option SUMMARY permet d’obtenir un affichage
résumé. L’affichage est le même qu’avec la commande LIST.
L’option VALIDATE permet de tester si la restauration correspondante peut être réalisée. RMAN
accède aux sauvegardes et vérifie qu’il peut en extraire les fichiers nécessaires. Il existe aussi une
commande VALIDATE BACKUPSET qui permet de tester des jeux de sauvegarde spécifiques (voir
la documentation Oracle).
c. La commande RECOVER
La syntaxe simplifiée de la commande RECOVER est la suivante :
RECOVER cible [options]

- cible
DATABASE
- options
DELETE ARCHIVELOG [MAXSIZE taille [K|M|G]]
L’option cible permet d’indiquer ce qu’il convient de récupérer : la base de données dans sa totalité,
ou des tablespaces ou fichiers de données spécifiques.
Lors de l’opération de récupération, RMAN recherche les fichiers de journalisation archivés dont il a
besoin, en premier lieu sur le disque. Les fichiers de journalisation archivés manquants sont
automatiquement restaurés à partir de sauvegardes, vers le répertoire d’archivage défini par le
paramètre LOG_ARCHIVE_DEST_1 (où vers une autre destination - voir la commande SET
ARCHIVELOG DESTINATION dans la documentation).
À la fin de l’opération, les fichiers de journalisation archivés restaurés ailleurs que dans la zone de
récupération rapide, ne sont pas supprimés par défaut. L’option DELETE ARCHIVELOG permet de
supprimer les fichiers de journalisation archivés restaurés qui ne sont plus nécessaires, au fur et à
mesure de leur application. L’option MAXSIZE permet au besoin, de limiter l’espace utilisé par
47 | P a g e


RMAN pour les fichiers de journalisation archivés restaurés. Si cette option est spécifiée, RMAN
procédera à la restauration des fichiers de journalisation archivés en plusieurs étapes, pour ne pas
dépasser la taille indiquée. Assurez-vous que la taille indiquée est supérieure à la taille des fichiers de
journalisation archivés, sinon vous obtiendriez une erreur.
La récupération peut utiliser des sauvegardes incrémentales ou des fichiers de journalisation archivés.
Si RMAN a le choix, il utilise en priorité les sauvegardes incrémentales.
6. Scénarios de récupération
a. Présentation
Dans cet ouvrage, nous allons présenter les scénarios de récupération de base suivants :
• récupération du fichier de paramètres serveur ;

• récupération d’un fichier de contrôle ;
• récupération d’un fichier de journalisation ;
• récupération complète de la totalité de la base de données en mode ARCHIVELOG ;
• récupération complète d’une partie de la base de données en mode ARCHIVELOG ;
• récupération de tous les fichiers de contrôle en mode ARCHIVELOG ;
• récupération incomplète en mode ARCHIVELOG ;
• récupération en mode NOARCHIVELOG.
En complément, nous évoquerons deux cas particuliers :
• récupération à un emplacement différent ;

• tablespace temporaire géré localement.
Dans un cas de récupération réel, vous serez peut-être amenés à combiner plusieurs de ces scénarios
de base. Par exemple, si vous avez perdu un fichier de contrôle et un tablespace, et si vous êtes en
mode ARCHIVELOG, vous appliquerez les scénarios suivants, dans l’ordre :
• récupération d’un fichier de contrôle ;

• récupération complète d’une partie de la base de données en mode ARCHIVELOG.
En règle générale, si vous avez perdu le fichier de paramètres serveur, un fichier de contrôle et/ou un
fichier de journalisation, vous devez d’abord résoudre ces problèmes avant de traiter le cas des fichiers
de données.
Tous ces scénarios sont basés sur les hypothèses suivantes :
• Vous avez activé la sauvegarde automatique du fichier de contrôle et du fichier de paramètres

serveur.
• Vous utilisez une zone de récupération rapide.
• Vous n’utilisez pas de base de données annexe pour stocker le catalogue RMAN.
Quel que soit le scénario, si le fichier est en fait simplement temporairement inaccessible (contrôleur disque
en panne par exemple), une restauration n’est pas nécessaire ; il suffit de corriger le problème pour rendre le
fichier de nouveau disponible et de redémarrer la base. Une restauration est néanmoins envisageable s’il
n’est pas possible d’attendre que le problème soit corrigé.
48 | P a g e


b. Récupération du fichier de paramètres serveur
En cas de perte du fichier de paramètres serveur, vous avez deux possibilités :
• Le recréer à partir d’un fichier de paramètres texte (voir le chapitre 7).

• Le récupérer à partir d’une sauvegarde RMAN.
Pour le récupérer à partir d’une sauvegarde automatique RMAN située dans la zone de récupération
rapide, le mode opératoire est le suivant :
• Démarrer l’instance sans monter la base de données (notez que RMAN va utiliser un fichier de
paramètres "temporaire" pour démarrer l’instance)
RMAN> STARTUP NOMOUNT

échec du démarrage : ORA-01078: failure in processing system parameters
LRM-00109: impossible d’ouvrir le fichier de paramètres
’D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\INITHERMES.ORA’
démarrage de l’instance Oracle sans fichier de paramètres
pour extraction de SPFILE
instance Oracle démarrée
Total System Global Area (SGA) 159019008 octets
Fixed Size 1331852 octets
Variable Size 67112308 octets
Database Buffers 88080384 octets
Redo Buffers 2494464 octets
• Restaurer le fichier de paramètres serveur à partir d’une sauvegarde automatique en spécifiant

l’emplacement de la zone de récupération rapide et le nom (ou le nom unique) de la base de
données
RMAN> RESTORE SPFILE FROM AUTOBACKUP

2> DB_RECOVERY_FILE_DEST ’H:\oradata\flash_recovery_area’
3> DB_NAME ’HERMES’;
Démarrage de restore dans 05/08/08
destination de la zone de récupération : H:\oradata\flash_recovery_area
nom de base de données (ou nom unique de base de données) utilisé pour
la recherche : HERMES
canal ORA_DISK_1 : AUTOBACKUP H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
AUTOBACKUP\2008_08_05\O1_MF_S_661968988_49JR5XWS_.BKP trouvé
dans la zone de récupération
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20080805
canal ORA_DISK_1 : restauration du fichier SPFILE à partir
de AUTOBACKUP H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\AUTOBACKUP\
2008_08_05\
O1_MF_S_661968988_49JR5XWS_.BKP
canal ORA_DISK_1 : restauration de SPFILE depuis AUTOBACKUP terminée
Fin de restore dans 05/08/08
• Redémarrer l’instance et ouvrir la base de données
RMAN> SHUTDOWN
...
RMAN> STARTUP
...
Si la sauvegarde automatique n’est pas stockée dans la zone de récupération rapide, le mode
opératoire est différent. Il faut positionner le DBID correspondant à la base de données (SET DBID
49 | P a g e


…), spécifier le format utilisé pour les sauvegardes automatiques (SET CONTROLFILE
AUTOBACKUP FORMAT …) avant de restaurer la sauvegarde par un RESTORE SPFILE FROM
AUTOBACKUP (sans autre option).
Il est aussi possible de restaurer le fichier de paramètre serveur en spécifiant la sauvegarde à

utiliser : RESTORE SPFILE FROM ’sauvegarde’.
c. Récupération d’un fichier de contrôle
Dans le cas où vous avez perdu un ou plusieurs fichiers de contrôle, mais qu’il vous en reste encore au
moins un, vous ne devez pas repartir d’une sauvegarde de fichier de contrôle. Vous allez simplement
dupliquer un des fichiers de contrôle restants pour remplacer les fichiers perdus.
Nous supposons que l’instance est arrêtée.
• utiliser le fichier d’alerte de l’instance pour identifier les fichiers de contrôle endommagés ou
perdus et en déduire qu’il reste bien au moins un fichier de contrôle valide ;
• dupliquer une version valide du fichier de contrôle pour la mettre à la place du (des) fichier(s)
de contrôle endommagé(s) ;
• redémarrer la base de données (STARTUP).
Si un fichier de contrôle est dupliqué à un autre emplacement que l’emplacement d’origine, il faut
modifier le paramètre CONTROL_FILES dans le fichier de paramètres serveur. Au lieu de redémarrer
directement la base de données, il faudra procéder de la manière suivante :
• Démarrer l’instance, sans monter la base de données
SQL> STARTUP NOMOUNT
• Modifier le paramètre CONTROL_FILES dans le fichier de paramètres serveur :
SQL> ALTER SYSTEM SET CONTROL_FILES=

2 ’f:\oradata\HERMES\control01.ctl’,
3 ’h:\oradata\HERMES\control02.ctl’ -- changement
4 SCOPE=SPFILE;
• Redémarrer l’instance

SQL> STARTUP
La duplication d’une version valide du fichier de contrôle peut s’effectuer dans RMAN, à l’aide d’une
variante de la commande RESTORE CONTROLFILE. Exemple :
RMAN> RESTORE CONTROLFILE FROM ’F:\oradata\HERMES\control01.ctl’ ;
La commande traite d’un seul coup tous les fichiers de contrôle manquants en se basant sur la valeur
du paramètre CONTROL_FILES.
50 | P a g e


Il est également possible de démarrer temporairement avec moins de fichiers de contrôle ; dans ce cas,
il sera aussi nécessaire de modifier la paramètre CONTROL_FILES dans le fichier de paramètres
serveur.
d. Récupération d’un fichier de journalisation
Si vous avez perdu un ou plusieurs fichiers de journalisation, mais qu’il vous en reste au moins un par
groupe, vous n’avez pas besoin de réaliser de restauration ou de récupération de la base de données.
Vous allez simplement recréer les fichiers de journalisation perdus.
• Identifier le (les) fichier(s) de journalisation endommagé(s) dans le fichier d’alerte de

l’instance, dans le fichier de trace de LGWR ou dans la vue V$LOGFILE.
• Supprimer le membre endommagé
SQL> ALTER DATABASE DROP LOGFILE MEMBER ’nom_fichier’;
• Ajouter un nouveau membre au groupe concerné
SQL> ALTER DATABASE ADD LOGFILE MEMBER ’nom_fichier’

2 TO GROUP numéro;
• Réitérer les deux opérations précédentes avec tous les membres endommagés.
Les fichiers de journalisation endommagés ont une colonne STATUS à INVALID dans la vue
V$LOGFILE.
Le fichier de journalisation ajouté peut être mis à un autre emplacement ; s’il est remis au même
emplacement que le précédent, il faudra peut-être au préalable supprimer physiquement l’ancien
fichier (s’il est présent, le mettre simplement de côté au cas où) ou utiliser la clause REUSE dans
l’ordre SQL.
Vous ne pourrez pas supprimer le membre s’il appartient au groupe courant. Dans ce cas, il faut
changer de groupe courant en exécutant l’ordre SQL ALTER SYSTEM SWITCH LOGFILE. Cet
ordre SQL 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 puisse pas être ouverte tout de suite, vous pouvez reporter la correction du problème à
plus tard ou vous contenter de recréer le membre ; la suppression pourra avoir lieu plus tard, une fois
la base de données ouverte.
Il peut être possible aussi de fonctionner temporairement avec moins de membres dans un groupe de
fichiers de journalisation.
e. Récupération complète de la totalité de la base de donnéesc en mode ARCHIVELOG
Ce scénario émet l’hypothèse que vous avez perdu tous les fichiers de données. L’instance est arrêtée.
RMAN> STARTUP MOUNT
51 | P a g e


• Restaurer la base de données
RMAN> RESTORE DATABASE ;

...
• Récupérer la base de données
RMAN> RECOVER DATABASE ;

Démarrage de recover dans 05/08/08
...
Fin de recover dans 05/08/08
RMAN> ALTER DATABASE OPEN ;
Si vous n’utilisez pas la zone de récupération rapide pour l’archivage, vous pouvez spécifier l’option
DELETE ARCHIVELOG dans la commande RECOVE pour supprimer les fichiers de journalisation
archivés restaurés au fur et à mesure de leur application et éventuellement limiter l’espace utilisé par
ces fichiers.
f. Récupération complète d’une partie de la base de données en mode ARCHIVELOG
Ce scénario émet l’hypothèse que vous avez perdu un ou plusieurs fichiers de données (mais pas
tous).
Cette opération peut être réalisée base fermée ou base ouverte, selon la nature du problème.
• Si un fichier de données du tablespace SYSTEM, ou un fichier du tablespace d’annulation

actif est perdu, l’instance s’est arrêtée et vous ne pourrez pas ouvrir la base de données sans
récupérer les fichiers en question.
• S’il s’agit d’un autre fichier de données, la base de données peut rester ouverte. Par contre, si
elle était fermée, elle ne peut pas être ouverte.
Récupération base de données fermée
Dans cet exemple, le fichier de données du tablespace SYSTEM est perdu ; l’instance est arrêtée.
• Monter la base de données :
RMAN> STARTUP MOUNT

...
• Restaurer les fichiers de données souhaités soit par un RESTORE TABLESPACE, soit par un
RESTORE DATAFILE
RMAN> RESTORE TABLESPACE system ;
52 | P a g e


• Récupérer les fichiers de données soit par un RECOVER TABLESPACE, soit par un
RECOVER DATAFILE
RMAN> RECOVER TABLESPACE system ;
RMAN> ALTER DATABASE OPEN ;

Récupération base de données ouverte
Dans cet exemple, le fichier de données du tablespace INDX est perdu (fichier de données numéro 6).
Si la base de données est fermée, mais que vous souhaitiez réaliser la récupération base ouverte (pour
que les utilisateurs puissent recommencer à travailler), commencez par la première partie du mode
opératoire. Si la base de données est déjà ouverte, passez directement à la deuxième partie du mode
opératoire.
La première partie du mode opératoire est la suivante :
RMAN> STARTUP MOUNT
• Mettre OFFLINE les fichiers de données perdus
RMAN> SQL "ALTER DATABASE DATAFILE 6 OFFLINE";
RMAN> ALTER DATABASE OPEN;
La deuxième partie du mode opératoire est la suivante :
• Passer OFFLINE les tablespaces concernés ; vous devez utiliser l’option IMMEDIATE, car un
fichier de données n’est pas accessible
RMAN> SQL "ALTER TABLESPACE indx OFFLINE IMMEDIATE";
• Restaurer les fichiers de données souhaités soit par un RESTORE TABLESPACE, soit par un
RESTORE DATAFILE
RMAN> RESTORE DATAFILE 6 ;
• Récupérer les fichiers de données soit par un RECOVER TABLESPACE, soit par un
RECOVER DATAFILE
RMAN> RECOVER DATAFILE 6 ;
• Passer ONLINE les tablespaces concernés
RMAN> SQL "ALTER TABLESPACE indx ONLINE";
53 | P a g e


g. Récupération de tous les fichiers de contrôle en mode ARCHIVELOG
Dans ce scénario, nous supposons que nous avons perdu tous les fichiers de contrôle ainsi qu’un
fichier de données. Il ne s’agit pas d’une catastrophe car nous disposons de sauvegardes automatiques
du fichier de contrôle (dans la zone de récupération rapide) et les fichiers de journalisation en ligne
sont disponibles. L’instance est arrêtée.
• Démarrer l’instance sans monter la base de données
• Restaurer les fichiers de contrôle à partir d’une sauvegarde automatique (dans la zone de
récupération rapide).
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT ;
1. Restaurer les fichiers de données perdus (déjà vu)
RMAN> RESTORE DATAFILE 5 ;
• Récupérer la base de données (pas uniquement les fichiers de données car nous repartons
d’une sauvegarde de fichiers de contrôle)
• Ouvrir la base de données avec l’option RESETLOGS (obligatoire)
RMAN> ALTER DATABASE OPEN RESETLOGS ;
• Vous obtenez une nouvelle "incarnation" de la base de données
RMAN> LIST INCARNATION OF DATABASE ;

Liste des incarnations de base de données
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- ------- ---------- ----------
1 1 HERMES 3535892647 PARENT 1 16/07/08
2 2 HERMES 3535892647 CURRENT 460308 05/08/08
Dans la commande RESTORE CONTROLFILE FROM AUTOBACKUP, vous pouvez spécifier les
options DB_RECOVERY_FILE_DEST et DB_NAME (ou DB_UNIQUE_NAME) si les valeurs
actuelles ne sont pas correctes. Par contre, si la sauvegarde automatique du fichier de contrôle n’est
pas stockée dans la zone de récupération rapide, le mode opératoire est différent. Il faut positionner le
DBID correspondant à la base de données (SET DBID …), spécifier le format utilisé pour les
sauvegardes automatiques (SET CONTROLFILE AUTOBACKUP FORMAT …) avant de restaurer
la sauvegarde par un RESTORE CONTROLFILE FROM AUTOBACKUP.
Lorsque vous repartez d’une sauvegarde de fichier de contrôle, RMAN effectue automatiquement un
CROSSCHECK et un CATALOG RECOVERY AREA pour mettre à jour le référentiel dans les
54 | P a g e


fichiers de contrôle (qui ne sont pas à jour puisqu’ils proviennent d’une sauvegarde), en fonction de la
réalité physique des fichiers.
Par ailleurs, vous devez ouvrir la base de donénes avec l’option RESETLOGS. Même si la
récupération est complète, Oracle considère que c’est une nouvelle vie de la base de données, une
nouvelle « incarnation » de la base de données. Les numéros de séquence des fichiers de
journalisation vont repartir de zéro.
Dans les versions précédentes d’Oracle, toutes les sauvegardes et tous les fichiers de journalisation
archivés antérieurs à l’ouverture en mode RESETLOGS étaient pratiquement inexploitables.
Depuis la version 10, ce n’est plus le cas. Lors d’une ouverture en mode RESETLOGS, Oracle associe
un numéro d’activation à la "nouvelle" base de données. Ce numéro d’activation est utilisé par Oracle
à différents endroits, dont le nom des fichiers de journalisation archivés (variable %r dans le
paramètre LOG_ARCHIVE_FORMAT). De cette manière, Oracle est capable d’associer n’importe
quel fichier à une incarnation de la base de données.
Le numéro d’activation courant peut être consulté dans la colonne INCARNATION# de la

vueV$DATABASE. L’historique des incarnations d’une base de données peut être consulté dans la
vue V$DATABASE_INCARNATION. Dans RMAN, la commande LIST INCARNATION donne la
liste des incarnations de la base de données.
Dans le fichier des alertes de l’instance, vous trouverez aussi des messages du type :
RESETLOGS after complete recovery through change 460307

Resetting resetlogs activation ID 3535886503 (0xd2c158a7)
Tue Aug 05 18:09:16 2008
Setting recovery target incarnation to 2

La notion d’incarnation de base de données est l’un des sujets les plus complexes d’Oracle.
h. Récupération incomplète en mode ARCHIVELOG
Ce scénario va illustrer la technique de récupération incomplète, en partant d’une situation

catastrophe : tout est perdu (fichier de paramètres serveur, fichiers de contrôle, fichiers de données et
fichiers de journalisation en ligne). L’instance est arrêtée.
Une récupération incomplète est nécessaire dans plusieurs cas :
• perte de tous les fichiers de journalisation en ligne (c’est le cas dans ce scénario) ;
• perte d’un fichier de journalisation archivé, nécessaire à une récupération ;
• retour avant un ordre SQL malencontreux (DROP TABLE, DROP TABLESPACE, DROP
USER, etc.).
Dans tous les cas, il faudra identifier le point de retour souhaité par une date/heure, un numéro SCN
ou un numéro de séquence de fichier de journalisation.
À la fin de la récupération, il faudra, là encore, ouvrir la base de données avec l’option

RESETLOGS : c’est une nouvelle incarnation de la base de données.
Ce scénario est une combinaison de scénarios déjà étudiés.
55 | P a g e


• Démarrer l’instance sans monter la base de données (RMAN utilise un fichier de paramètres
"temporaire" car le fichier de paramètres serveur est perdu) :

échec du démarrage : ...
démarrage de l’instance Oracle sans fichier de paramètres ...
...
• Restaurer le fichier de paramètres serveur à partir d’une sauvegarde automatique (stockée dans
la zone de récupération rapide pour cet exemple) :
RMAN> RESTORE SPFILE FROM AUTOBACKUP

2> DB_RECOVERY_FILE_DEST ’H:\oradata\flash_recovery_area’
3> DB_NAME ’HERMES’;
• Redémarrer l’instance sans monter la base de données (démarrage avec le fichier de

paramètres serveur restauré) :
RMAN> STARTUP NOMOUNT FORCE
• Restaurer les fichiers de contrôle à partir d’une sauvegarde automatique (stockée dans la zone
de récupération rapide pour cet exemple) :
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP ;
• Monter la base de données :
• Restaurer et récupérer la base de données :
RMAN> RESTORE DATABASE ;

...
...
RMAN-03002: échec de la commande recover à 08/06/2008 07:37:00
RMAN-06054: la récupération après défaillance matérielle requiert
un journal inconnu : thread 1, séquence 7 et SCN de début 475124
• Ouvrir la base de données avec l’option RESETLOGS :
Dans ce scénario, avec le mode opératoire utilisé ici, il est normal que la commande RECOVER se
termine avec une erreur puisqu’il manque un fichier de journalisation. Au préalable, la commande
RESTORE a effectué automatiquement un CROSSCHECK et un CATALOG RECOVERY AREA
pour mettre à jour le référentiel (notamment les fichiers de journalisation archivés disponibles) dans
les fichiers de contrôle ; la commande RECOVER est donc, allée le plus loin possible avec les
éléments à sa disposition. Avant d’ouvrir la base dans le mode RESETLOGS, assurez-vous que le
numéro de séquence du dernier fichier de journalisation appliqué est conforme à vos attentes.
56 | P a g e


Dans le cas où nous souhaitons préciser explicitement le point de retour, il est possible d’utiliser une
clause UNTIL dans les commandes RESTORE et RECOVER ; cette clause offre plusieurs options :
UNTIL SCN [=] n
Jusqu’à un numéro SCN (non compris).
UNTIL SEQUENCE[=] n
Jusqu’à un numéro de séquence d’un fichier de journalisation (non compris).
UNTIL TIME [=]’date’
Jusqu’à une date/heure (non comprise). Peut être spécifié sous la forme d’une constante (au format de
date courant) ou une expression du type ’SYSDATE-1’ ou "TO_DATE(…)".
Dans un bloc RUN, il est aussi possible d’utiliser la commande SET UNTIL avant d’exécuter les
commandes RESTORE et RECOVER :
RUN
{
SET UNTIL ... ;
RESTORE DATABASE ;
RECOVER DATABASE ;}
i. Récupération en mode NOARCHIVELOG
Dans ce scénario, nous supposons que nous avons perdu tout ou partie de la base de données et que
cette dernière fonctionne en mode NOARCHIVELOG.
Dans ce cas, normalement, la seule solution de récupération consiste à ramener la base de données à
l’état où elle se trouvait lors de la dernière sauvegarde complète base fermée, cette dernière pouvant
être une sauvegarde incrémentale.
Néanmoins, comme nous l’avions indiqué précédemment, il est peut être envisageable de réaliser une
récupération complète si les fichiers de journalisation sont disponibles et qu’il n’y ait pas eu un cycle
complet de basculement des fichiers de journalisation depuis la dernière sauvegarde. Vous pouvez
alors tenter une restauration de type ARCHIVELOG (points e. ou f.) :
• restauration des fichiers de données endommagés ;

• récupération des fichiers de données endommagés.
Si la récupération ne signale pas d’erreur, c’est gagné. Par contre, si la récupération signale une erreur
du type suivant, la situation est a priori désespérée :
journal d’archivage introuvable

journal d’archivage, thread=1, séquence=7
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: échec de la commande recover à 08/06/2008 07:37:00
RMAN-06054: la récupération après défaillance matérielle requiert un
journal inconnu : thread 1, séquence 7 et SCN de début 475124
57 | P a g e


Dans ce cas, il ne reste plus qu’à réaliser une récupération en mode NOARCHIVELOG, à l’aide du
mode opératoire suivant :
• Démarrer l’instance sans monter la base de données
• Restaurer les fichiers de contrôle à partir d’une sauvegarde automatique (stockée dans la zone
de récupération rapide pour cet exemple)
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
• Restaurer la base de données
RMAN> RESTORE DATABASE;
• Si vous utilisez des sauvegardes incrémentales cohérentes (base fermée) de la totalité de la

base de données, la commande RESTORE précédente aura ramené la dernière sauvegarde de
niveau 0. Vous pouvez alors réaliser une récupération (RECOVER) avec l’option NOREDO,
pour que RMAN applique les sauvegardes incrémentales de niveau 1 postérieur à la
sauvegarde de niveau 0, sans appliquer les fichiers de journalisation.
RMAN> RECOVER DATABASE NOREDO;
• Ouvrir la base de données avec l’option RESETLOGS (obligatoire)
Là encore, vous obtenez une nouvelle incarnation de la base de données ; c’est normal puisque vous
être revenu à un instant donné du passé.
j. Récupération à un emplacement différent
Dans certains cas, il peut être impossible de restaurer les fichiers de données dans l’arborescence
d’origine. Il faudra alors utiliser deux commandes supplémentaires dans le processus de restauration :
• Avant la restauration (RESTORE) : SET NEWNAME FOR DATAFILE pour indiquer à

RMAN le nouvel emplacement d’un fichier de données
SET NEWNAME FOR DATAFILE ’ancien_chemin’ | numéro_fichier

TO ’nouveau_chemin’ ;
• Après la restauration (RESTORE) et avant la récupération (RECOVER) : SWITCH

DATAFILE pour mettre à jour le fichier de contrôle (équivalent à l’ordre SQL ALTER
DATABASE RENAME FILE)
SWITCH DATAFILE ALL ;
Ces deux commandes doivent être exécutées dans un bloc RUN.
58 | P a g e


Exemple pour restaurer un fichier de données à un autre emplacement
RUN
{
# si l’instance est arrêtée, la démarrer
# et monter la base de données
STARTUP MOUNT
#
# si la base de données est ouverte,
# mettre le tablespace OFFLINE
# SQL "ALTER TABLESPACE data OFFLINE IMMEDIATE" ;
#
SET NEWNAME FOR DATAFILE ’e:\oradata\HERMES\data01.dbf’
TO ’f:\oradata\HERMES\data01.dbf’ ;
RESTORE TABLESPACE data ;
SWITCH DATAFILE ALL ;
RECOVER TABLESPACE data ;
# si la base de données est montée, l’ouvrir

ALTER DATABASE OPEN ;
#
# si la base de données est ouverte,
# mettre le tablespace ONLINE
# SQL "ALTER TABLESPACE data ONLINE" ;
}
k. Cas particulier du 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.
Si vous perdez un fichier de données d’un tablespace temporaire géré localement, vous n’avez
normalement rien de particulier à faire car Oracle le recrée, si besoin, automatiquement lors de
l’ouverture de la base de données. Dans le fichier d’alerte de l’instance, vous trouverez alors des
messages du type suivant :
2008-08-07 06:58:51.171000 +02:00

Re-creating tempfile E:\ORADATA\HERMES\TEMP01.DBF
Pour vérifier que les fichiers de données des tablespaces temporaire gérés localement sont bien
présents, vous pouvez interroger la vue V$TEMPFILE ou exécuter la commande RMAN REPORT
SCHEMA.
En cas de besoin, vous pouvez explicitement recréer les fichiers de données des tablespaces gérés
localement. Exemple :
SQL> ALTER TABLESPACE temp

2 ADD TEMPFILE ’e:\oradata\HERMES\temp01.dbf’ SIZE 100M
3 AUTOEXTEND ON NEXT 100M MAXSIZE 1G;
7. Data Recovery Advisor
a. Vue d’ensemble
Le Data Recovery Advisor est un outil qui permet de simplifier et d’automatiser le diagnostic et la
résolution des problèmes (perte ou corruption) sur les fichiers de la base données. Cet outil est apparu
en version 11.
59 | P a g e


Le conseiller peut être utilisé en ligne de commande dans RMAN ou avec une interface graphique
dans le Database Control (cf. Utiliser le Database Control).
Dans la terminologie du conseiller, un échec (failure en anglais) sur un fichier est identifié par un
numéro unique et est caractérisé par un statut (OPEN ou CLOSED) et une priorité (LOW, HIGH ou
CRITICAL).
Le statut est OPEN tant que le problème n’a pas été résolu ; il passe à CLOSED ensuite.
La priorité est CRITICAL lorsque la base de données est totalement indisponible et HIGH si elle est
partiellement indisponible ; dans les deux cas, il convient de résoudre le problème rapidement. La
priorité LOW n’est pas attribuée par le conseiller. Par contre, si vous jugez qu’une priorité HIGH a
peu d’impact sur le fonctionnement de la base de données et ne nécessite pas de traitement immédiat,
vous pouvez descendre manuellement la priorité à LOW.
Les informations relatives aux échecs sont stockées dans le référentiel de diagnostic automatique.
Pour fonctionner, le Data Recovery Advisor nécessite que l’instance soit démarrée (mais la base de
donnée peut ne pas être montée ce qui permet de diagnostiquer et résoudre les incidents sur les
fichiers de contrôle).
b. Utilisation
Dans RMAN, les étapes pour diagnostiquer et résoudre les problèmes à l’aide du conseiller sont les
suivantes :
• Afficher les échecs actuels (statut OPEN) : LIST FAILURE.

• Déterminer les actions à effectuer pour résoudre le(s) problème(s) : ADVISE FAILURE.
• Résoudre le(s) problème(s) : REPAIR FAILURE.
• Retourner à l’étape 1 pour confirmer que les problèmes ont été résolus ou voir s’il reste encore
des problèmes.
Au préalable, il est possible d’exécuter la commande VALIDATE DATABASE pour vérifier la

totalité de la base de données (mais il faut que la base de données soit montée).
En complément des commandes LIST FAILURE, ADVISE FAILURE et REPAIR FAILURE, il

existe une commande CHANGE FAILURE qui permet de modifier le statut ou la priorité. Cette
commande, moins utile, n’est pas présentée dans cet ouvrage (voir la documentation "Oracle®
Database Backup and Recovery Reference").
La première étape consiste donc à afficher les échecs actuels avec la commande LIST FAILURE.
Syntaxe simplifiée
LIST FAILURE [quoi] [DETAIL] ;
La clause quoi peut prendre une ou plusieurs des valeurs suivantes : ALL, CRITICAL, HIGH, LOW,
CLOSED ou un numéro d’échec.
Par défaut, la commande LIST FAILURE affiche tous les échecs de statut OPEN et de priorité
CRITICAL ou HIGH. L’option CLOSED permet d’afficher les échecs de statut CLOSED. Les
options CRITICAL, HIGH, LOW ou ALL permettent d’afficher les échecs ayant une priorité donnée
(ALL = toutes les priorités).
60 | P a g e


Pour simplifier, les échecs de même nature sont regroupés dans un seul échec "parent" et seuls ces
derniers sont affichés par défaut par la commande LIST FAILURE. Pour afficher tous les échecs
"enfants", vous pouvez utiliser l’option DETAIL.
Exemple
RMAN> LIST FAILURE ;

utilisation du fichier de contrôle de la base de données
cible au lieu du catalogue de récupération
Liste des échecs de base de données
=========================
ID d’échec Priority Status Time Detected Summary
---------- -------- ------ ------------- -------
565 HIGH OPEN 07/08/08 Un ou plusieurs fichiers de
données non système sont absents
RMAN> LIST FAILURE 565 DETAIL;
utilisation du fichier de contrôle de la base de données cible
au lieu du catalogue de récupération
=========================
---------- -------- ------ ------------- -------
565 HIGH OPEN 07/08/08 Un ou plusieurs fichiers
de données non système sont absents
Impact : Voir l’impact des échecs des enfants
Liste des échecs enfant de l’ID d’échec parent 565
---------- ------ ------ ------------- -------
1859 HIGH OPEN 07/08/08 Le fichier
de données 6: ’E:\ORADATA\HERMES\INDX01.DBF’ est absent
Impact : Il se peut que certains objets dans
le tablespace INDX soient indisponibles
1853 HIGH OPEN 07/08/08 Le fichier
de données 5: ’E:\ORADATA\HERMES\DATA01.DBF’ est absent
Impact : Il se peut que certains objets dans
le tablespace DATA soient indisponibles
Sur cet exemple, un problème a été détecté sur deux fichiers de données.
Pour générer et afficher les actions à effectuer pour traiter les échecs, vous devez utiliser la commande
ADVISE FAILURE.
Syntaxe simplifiée
ADVISE FAILURE [quoi] ;
La clause quoi peut prendre une ou plusieurs des valeurs suivantes : ALL, CRITICAL, HIGH, LOW
ou un numéro d’échec.
La commande ADVISE FAILURE sans option peut être utilisée uniquement si une commande LIST
FAILURE a été exécutée au préalable dans la session RMAN. Dans ce cas, la commande ADVISE
FAILURE affiche des informations de résolution pour tous les échecs de statut OPEN et de priorité
CRITICAL ou HIGH enregistrés dans le référentiel de diagnostic automatique.
Les options de la clause quoi permettent d’afficher les informations de résolution pour un sous-
ensemble d’échecs ; la signification des différentes options de cette clause est la même que pour la
commande LIST FAILURE.
61 | P a g e


Exemple
RMAN> ADVISE FAILURE ;

=========================
---------- -------- ------ ------------- -------
565 HIGH OPEN 07/08/08 Un ou plusieurs fichiers
de données non système sont absents
...
analyse des options de réparation automatique ; cette opération
peut prendre un certain temps
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : SID=208 type d’unité=DISK
analyse des options de réparation automatique terminée
Actions manuelles obligatoires
========================
aucune action manuelle n’est disponible
Actions manuelles facultatives
=======================
1. Si le fichier E:\ORADATA\HERMES\DATA01.DBF a été renommé ou déplacé
involontairement, restaurez-le
2. Si le fichier E:\ORADATA\HERMES\INDX01.DBF a été renommé ou déplacé
involontairement, restaurez-le
Options de réparation automatique
========================
Option Repair Description
------ ------------------
1 Restaurez et récupérez le fichier de données 5; Restaurez
et récupérez le fichier de données 6
Stratégie : La réparation comprend une récupération après défaillance
matérielle sans perte de données
Script de réparation : d:\app\oracle\diag\rdbms\hermes\hermes\hm\
reco_499244267.hm
Après avoir affiché des informations sur les échecs trouvés (résultat de la commande LIST
FAILURE), la commande ADVISE FAILURE affiche trois sections :
Actions manuelles obligatoires : cette section liste les opérations qui doivent obligatoirement être
faites manuellement pour résoudre le problème. Des actions manuelles obligatoires peuvent, par
exemple, être nécessaires si une sauvegarde ou un fichier de journalisation archivé requis par la
réparation automatique sont manquants.
Actions manuelles facultatives : cette section liste les opérations manuelles facultatives qui peuvent
permettre de résoudre le problème. Par exemple, si un fichier de données est manquant, le conseiller
suggère que ce fichier a peut-être été involontairement renommé ou déplacé et qu’il peut donc être
restauré sans devoir repartir d’une sauvegarde.
Options de réparation automatique : cette section liste les différentes options de réparation
automatique. Pour chaque option, la commande affiche un numéro, une description, une stratégie
(avec ou sans perte de données) et le chemin du script qui contient les commandes de réparation. Les
options correspondant à une stratégie sans perte de données sont toujours proposées en premier.
Pour réparer automatiquement les échecs identifiés par le Data Recovery Advisor, vous pouvez
utiliser la commande REPAIR FAILURE.
Syntaxe
62 | P a g e


REPAIR FAILURE [USING ADVISE OPTION numéro] [PREVIEW] [NOPROMPT];
Par défaut, la commande REPAIR FAILURE exécute les actions de la première option de réparation
automatique, identifiée par la commande ADVISE FAILURE la plus récente exécutée dans la session
RMAN ; si aucune commande ADVISE FAILURE n’a été exécutée dans la session RMAN, une
erreur est retournée.
L’option USING ADVISE OPTION permet d’appliquer une option de réparation automatique
spécifique, identifiée par son numéro d’option.
L’option PREVIEW permet de ne pas exécuter les actions, mais simplement de les prévisualiser à
l’écran.
L’option NOPROMPT permet de supprimer la demande de confirmation, lors de l’exécution effective

de la commande.
Exemple
RMAN> REPAIR FAILURE PREVIEW ;

reco_499244267.hm
contenu du script de réparation :
# restore and recover datafile
restore datafile 5, 6;
recover datafile 5, 6;
RMAN> REPAIR FAILURE NOPROMPT ;
reco_499244267.hm
contenu du script de réparation :
# restore and recover datafile
restore datafile 5, 6;
recover datafile 5, 6;
exécution du script de réparation
...
...
Fin de recover dans 07/08/08
réparation de l’échec terminée
base de données ouverte
Lors de l’exécution effective des actions de réparation, RMAN affiche le résultat des différentes
commandes exécutées (RESTORE, RECOVER, etc.).
c. Considérations
Le Data Recovery Advisor est un outil très puissant qui permet de diagnostiquer et résoudre un grand
nombre de problèmes sur les fichiers de contrôle, les fichiers de journalisation ou les fichiers de
données.
63 | P a g e


Le seul problème que le Data Recovery Advisor ne sait pas résoudre est la perte du fichier de
paramètres serveur. Si besoin, vous devrez restaurer manuellement le fichier de paramètre serveur (cf.
Récupération)
Avant d’utiliser le conseiller, assurez-vous que l’instance a bien démarré avec un fichier de
paramètres à jour. Si ce n’est pas le cas, le conseiller risque de signaler un faux problème sur les
fichiers de contrôle si la valeur du paramètre CONTROL_FILES n’est pas correcte. Vous pouvez
notamment rencontrer cette situation si RMAN a démarré l’instance avec un fichier de paramètre
"temporaire" (message démarrage de l’instance Oracle sans fichier de paramètres pour extraction de
SPFILE).
Dans le cas où tous les fichiers de contrôle sont perdus, le Data Recovery Advisor commencera par
signaler ce problème et ne sera pas forcément en mesure d’identifier tout de suite d’autres problèmes
(sur les fichiers de données par exemple). Vous devrez donc, d’abord traiter le problème sur les
fichiers de contrôle (LIST FAILURE, puis ADVISE FAILURE puis REPAIR FAILURE) avant de
faire de nouveau appel au conseiller pour identifier les autres problèmes éventuels (LIST FAILURE)
et si besoin, les résoudre (ADVISE FAILURE puis REPAIR FAILURE).
Cette situation peut se produire dans le scénario catastrophe où vous avez perdu la totalité de la base
de données (tous les fichiers de contrôle, tous les fichiers de journalisation et tous les fichiers de
données).
Là encore, utiliser une zone de récupération rapide, et faire des sauvegardes automatiques du fichier
de contrôle vers cette zone de récupération rapide, facilite la résolution des problèmes par le Data
Recovery Advisor.
Si la situation l’exige (récupération incomplète ou récupération à partir d’une sauvegarde des fichiers
de contrôle), le Data Recovery Advisor ouvrira la base de données dans le mode RESETLOGS.
Les techniques de flashback

1. Vue d’ensemble
Les techniques de flashback sont un ensemble de fonctionnalités proposées par Oracle qui permettent
de voir l’état passé des données, ou de ramener une table ou la totalité de la base de données dans le
passé.
Les fonctionnalités proposées sont les suivantes :
• Flashback Query: permet de lire les données telles qu’elles étaient à un instant dans le passé
(apparu en version 9).
• Flashback Version Query : permet de voir toutes les versions d’une ligne sur un certain
intervalle de temps (apparu en version 10).
• Flashback Transaction Query : permet de voir les modifications réalisées par une ou plusieurs
transactions sur un certain intervalle de temps (apparu en version 10).
• Flashback Transaction: permet d’annuler les modifications d’une transaction, et de ses
transactions dépendantes (apparu en version 11).
• Flashback Data Archive (Oracle Total Recall) : permet de conserver sur le long terme, toutes
les modifications apportées à une table (apparu en version 11).
• Flashback Table : permet de ramener une table dans l’état où elle était, à un certain moment
dans le passé (apparu en version 10).
64 | P a g e


• Flashback Drop: permet de ramener la table dans l’état où elle était, juste avant sa suppression
(apparu en version 10).
• Flashback Database : permet de ramener la totalité de la base de données dans l’état où elle
était à un certain moment dans le passé (apparu en version 11).
Seule la fonctionnalité Flashback Query est disponible dans toutes les éditions de la base de données
(et donc notamment en Standard Edition).
La fonctionnalité Flashback Data Archive (Oracle Total Recall) est une option de l’Enterprise Edition
et nécessite donc, une licence supplémentaire. Cette fonctionnalité n’est pas présentée dans cet
ouvrage.
Les autres fonctionnalités de flashback nécessitent l’Enterprise Edition, mais sans option
supplémentaire.
Ces fonctionnalités utilisent des techniques différentes mais pour répondre au même
objectif : récupérer une erreur d’utilisation.
Les fonctionnalités de flashback de requête (Flashback Query, Flashback Version Query et Flashback
Transaction Query), et la fonctionnalité de flashback de table, utilisent les informations d’annulation
pour revenir en arrière. Le paramètre UNDO_RETENTION et le tablespace d’annulation doivent
donc être correctement dimensionnés, si vous souhaitez pouvoir retourner loin dans le passé.
La fonctionnalité de flashback de transaction (Flashback Transaction) utilise les fichiers de

journalisation (en ligne et archivés, donc la base de données doit fonctionner dans le mode
ARCHIVELOG). Cette fonctionnalité, un peu avancée, n’est pas présentée dans cet ouvrage.
La fonctionnalité de flashback de base de données (Flashback Database) utilise un fichier journal

spécifique, différent des fichiers de journalisation.
La fonctionnalité de flashback avant suppression d’une table (Flashback Drop) utilise le fait que le
stockage d’une table n’est pas physiquement supprimé lorsque la table est supprimée.
2. Niveau ligne
Flashback Query
Pour lire les données telles qu’elles étaient à un instant donné du passé, vous pouvez utiliser l’option
AS OF sur une table présente dans la clause FROM d’une requête SELECT.
Syntaxe
nom_table AS OF { TIMESTAMP | SCN } expression
L’option TIMESTAMP permet de retourner à un instant donné du passé en indiquant une date et une
heure ; dans ce cas, l’expression doit être de type TIMESTAMP. L’option SCN permet de retourner à
un instant donné du passé en indiquant un numéro SCN ; dans ce cas, l’expression doit être un
nombre.
Exemple
-- situation de départ
SQL> SELECT prenom FROM adherent WHERE numero = 1;
65 | P a g e


PRENOM
----------------------------------------
Sébastien
SQL> SELECT TO_CHAR(SYSDATE,’DD/MM/YYYY HH24:MI:SS’) "SYSDATE",
2 dbms_flashback.get_system_change_number "SCN"
3 FROM dual;
SYSDATE SCN
-------------------- ----------
08/08/2008 11:28:00 176032
SQL> -- un peu plus tard

SQL> UPDATE adherent SET prenom = ’Olivier’ WHERE numero = 1;
1 ligne mise à jour.
SQL> COMMIT;
Validation effectuée.
SQL> -- un peu plus tard

SQL> SELECT TO_CHAR(SYSDATE,’DD/MM/YYYY HH24:MI:SS’) "SYSDATE",
2 dbms_flashback.get_system_change_number "SCN"
3 FROM dual;
SYSDATE SCN
-------------------- ----------
08/08/2008 11:28:20 176123
SQL> SELECT prenom
2 FROM adherent AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL ’30’ SECOND
3 WHERE numero = 1;
PRENOM
----------------------------------------
Sébastien
SQL> SELECT prenom
2 FROM adherent AS OF SCN 176032
3 WHERE numero = 1;
PRENOM
----------------------------------------
Sébastien
SQL> SELECT prenom FROM adherent WHERE numero = 1;
PRENOM
----------------------------------------
Olivier

La fonction GET_SYSTEM_CHANGE_NUMBER du package DBMS_FLASHBACK retourne le numéro SCN courant.
Il faut le privilège EXECUTE sur le package pour l’utiliser.
La donnée lue dans le passé peut être utilisée pour réaliser une mise à jour dans le présent :
SQL> UPDATE adherent

2 SET nom = (SELECT prenom FROM adherent AS OF SCN 176032
3 WHERE numero = 1)
4 WHERE numero = 1;
Flashback Version Query
Pour lire les différentes versions d’une ligne sur un certain intervalle de temps, vous pouvez utiliser
l’option VERSIONS BETWWEN sur une table présente dans la clause FROM d’une requête
SELECT.
Syntaxe
nom_table VERSIONS BETWEEN { TIMESTAMP | SCN }
66 | P a g e


{ expression1 | MINVALUE } AND { expression2 | MAXVALUE }
La signification des options TIMESTAMP et SCN est la même que dans la clause AS OF.
MINVALUE et MAXVALUE permettent d’obtenir la plus ancienne ligne et la plus récente.En
complément, vous pouvez utiliser plusieurs pseudo-colonnes qui vous donneront des informations sur
les différentes versions de la ligne :
VERSIONS_STARTTIME
Date/heure de début de validité de la version de la ligne.
VERSIONS_STARTSCN
Numéro SCN de début de validité de la version de la ligne.
VERSIONS_ENDTIME
Date/heure de fin de validité de la version de la ligne.
VERSIONS_ENDSCN
Numéro SCN de fin de validité de la version de la ligne.
VERSIONS_XID
Identifiant de la transaction à l’origine de la version de la ligne.
VERSIONS_OPERATION
Opération à l’origine de la version de la ligne : I pour INSERT, U pour UPDATE et D pour DELETE.
Exemple
SQL> BEGIN
2 INSERT INTO adherent(numero,prenom) VALUES(24,’Olivier’);
3 COMMIT;
4 UPDATE adherent SET prenom = ’David’ WHERE numero = 24;
5 COMMIT;
6 DELETE FROM adherent WHERE numero = 24;
7 COMMIT;
8 END;
9 /
Procédure PL/SQL terminée avec succès.
SQL> SELECT versions_startscn, versions_endscn,
2 versions_xid, versions_operation,
3 prenom
4 FROM adherent VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE
5 WHERE numero = 24
6 ORDER BY versions_startscn;
VERSIONS_STARTSCN VERSIONS_ENDSCN VERSIONS_XID V PRENOM

----------------- --------------- ---------------- - ----------
177002 177003 030012000D010000 I Olivier
177003 177004 020019000E010000 U David
177004 01000D0008010000 D David

67 | P a g e


Une nouvelle version d’une ligne est créée lors d’un COMMIT.
Flashback Transaction Query
Pour voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de
temps, vous pouvez interroger la vue FLASHBACK_TRANSACTION_QUERY. Cette vue donne des
informations sur toutes les transactions de la base de données pouvant faire l’objet d’un flashback. Les
principales colonnes de cette vue sont les suivantes :
XID
Identifiant de la transaction.
START_SCN
Numéro SCN de début de la transaction.
START_TIMESTAMP
Date/heure de début de la transaction.
COMMIT_SCN
Numéro SCN du COMMIT de la transaction (vide pour la transaction en cours).
COMMIT_TIMESTAMP
Date/heure du COMMIT de la transaction (vide pour la transaction en cours).
LOGON_USER
Compte utilisateur de la session.
OPERATION
Opération réalisée dans la transaction : INSERT, UPDATE, DELETE.
TABLE_NAME
Nom de la table concernée par l’opération.
TABLE_OWNER
Propriétaire de la table concernée par l’opération.
ROW_ID
ROWID de la ligne concernée par l’opération.
UNDO_SQL
Ordre SQL permettant d’annuler l’opération.
68 | P a g e


Vous pouvez interroger cette vue de différentes manières :
• par le nom d’une table sur laquelle vous avez noté un problème ;
• par le ROWID d’une ligne sur laquelle vous avez noté un problème ;
• par un identifiant de transaction relevé en analysant les différents versions d’une ligne
(pseudo-colonne VERSIONS_XID).
Exemple
SQL> SELECT xid, start_scn,commit_scn, logon_user, undo_sql

2 FROM flashback_transaction_query
3 WHERE table_name=’ADHERENT’ AND table_owner=’DIANE’
4 AND operation =’DELETE’ AND start_timestamp > SYSDATE-1;
XID START_SCN COMMIT_SCN LOGON_USER
---------------- ---------- ---------- ---------------
UNDO_SQL
-----------------------------------------------------------------
...
030006000D010000 176702 176712 DIANE
insert into "DIANE"."ADHERENT"("NUMERO","NOM","PRENOM","SEXE","DATE_
NAISSANCE","TELEPHONE","REF_CATEGORIE") values (’22’,NULL,
’Olivier’,NULL,NULL,NULL,NULL);
030006000D010000 176702 176712 DIANE
insert into "DIANE"."ADHERENT"("NUMERO","NOM","PRENOM","SEXE","DATE_
NAISSANCE","TELEPHONE","REF_CATEGORIE") values (’21’,’HEURTEL’
,NULL,NULL,NULL,NULL,NULL);
...
Sur cet exemple, nous recherchons toutes les transactions qui ont fait un DELETE sur la table
ADHERENT du schéma DIANE, la dernière journée. Les deux lignes affichées appartiennent à la
même transaction (même XID). La colonne UNDO_SQL donne l’ordre SQL qui peut être utilisé pour
récréer la ligne.
3. Niveau table
Flashback Table
Pour ramener une table à l’état où elle était à un moment donné du passé, vous pouvez utiliser l’ordre
SQL FLASHBACK TABLE.
Syntaxe
FLASHBACK nom_table [,…] TO instant

[ENABLE TRIGGERS] ;
instant
{ TIMESTAMP | SCN } expression
| RESTORE POINT nom
La signification des options TIMESTAMP et SCN est la même que dans la clause AS OF. L’option
RESTORE POINT permet de revenir à un point de retour créé au préalable avec l’ordre SQL
CREATE RESTORE POINT ; les points de retour sont visibles dans la vue V$RESTORE_POINT.
L’option ENABLE TRIGGERS permet d’autoriser le déclenchement des triggers qui existent et qui
sont actuellement actifs ; par défaut, ils ne sont pas déclenchés.
Pour réaliser cette opération, il faut :
69 | P a g e


• avoir le privilège objet FLASHBACK sur la table ou le privilège système FLASHBACK ANY
TABLE ;
• détenir les privilèges objet SELECT, INSERT, et ALTER sur la table (ou les privilèges
système ANY correspondants) ;
• que le déplacement de lignes soit autorisé sur la table (ROW MOVEMENT).
Exemple
-- je supprime toutes les lignes d’une table

SQL> DELETE FROM diane.adherent;
20 lignes supprimées.
SQL> COMMIT;
Validation effectuée.
SQL> SELECT COUNT(*) FROM diane.adherent;

COUNT(*)
----------
0
-- 5 minutes plus tard, je m’aperçoit de mon erreur ...

SQL> FLASHBACK TABLE diane.adherent
2 TO TIMESTAMP SYSTIMESTAMP - INTERVAL ’5’ MINUTE;
FLASHBACK TABLE diane.adherent TO TIMESTAMP SYSTIMESTAMP - INTERVAL
’5’ MINUTE
*
ERROR at line 1:
ORA-08189: opération Flashback impossible sur la table : le mouvement
de ligne n’est pas activé
-- il faut autoriser le déplacement de lignes

SQL> ALTER TABLE diane.adherent ENABLE ROW MOVEMENT;
Table modifiée.
SQL> FLASHBACK TABLE diane.adherent

2 TO TIMESTAMP SYSTIMESTAMP - INTERVAL ’5’ MINUTE;
Flashback terrminé.
SQL> SELECT COUNT(*) FROM diane.adherent;

COUNT(*)
----------
20
-- c’est cool ...
Flashback Drop
Depuis la version 10, lorsqu’une table est supprimée, elle ne l’est pas complètement, sauf si vous
utilisez l’option PURGE de l’ordre SQL DROP TABLE ; elle est placée dans une "corbeille". Dans
les grandes lignes, une table supprimée est en fait renommée par Oracle, et l’espace associé n’est pas
récupéré immédiatement (bien qu’il apparaisse dans la vue DBA_FREE_SPACE) ; Oracle fait la
même chose avec les dépendances de l’objet, notamment les index. L’espace de stockage des objets se
trouvant dans la corbeille n’est pas réutilisé, sauf en cas de manque d’espace dans le tablespace.
Si Oracle a besoin d’allouer une nouvelle extension dans un tablespace, et qu’il n’y ait plus
suffisamment de place, Oracle récupèrera l’espace correspondant aux objets de la corbeille, en
commençant par les objets les plus anciens (FIFO : First In First Out). Oracle réalise cette
récupération avant de faire grandir le fichier de données du tablespace si celui-ci a la propriété
AUTOEXTEND.
70 | P a g e


La "corbeille" se matérialise tout simplement par une table du dictionnaire de données qui peut être
interrogée à l’aide des vues USER_RECYCLEBIN et DBA_RECYCLEBIN, ou à l’aide de la
commande SQL*Plus SHOW RECYCLEBIN (interroge la vue USER_ RECYCLEBIN).
Les colonnes les plus intéressantes de la vue DBA_RECYCLEBIN sont les suivantes :
OWNER
Nom du propriétaire de l’objet.
OBJECT_NAME
Nom de l’objet dans la corbeille.
ORIGINAL_NAME
Nom d’origine de l’objet.
TYPE
Type de l’objet (TABLE, INDEX, TRIGGER, etc.).
TS_NAME
Nom du tablespace dans lequel l’objet est stocké.
CREATETIME
Date de création de l’objet.
DROPTIME
Date de suppression de l’objet.
CAN_UNDROP
Indique si l’objet peut être sorti de la corbeille (YES ou NO).
CAN_PURGE
Indique si l’objet peut être définitivement supprimé (YES ou NO).
SPACE
Nombre de blocs utilisés par l’objet.
En complément, les vues DBA_INDEXES et DBA_TABLES contiennent une colonne DROPPED

indiquant si la table ou l’index est supprimé (YES ou NO).
Pour "annuler" la suppression d’une table, vous pouvez utiliser une variante de l’ordre SQL
FLASHBACK TABLE.
71 | P a g e


Syntaxe
FLASHBACK TABLE nom_table TO BEFORE DROP [RENAME TO nouveau_nom] ;
Dans la commande FLASHBACK TABLE, vous pouvez utiliser le nom d’origine de l’objet ou le
nom de l’objet dans la corbeille.
Si plusieurs tables dans la corbeille ont le même nom d’origine (table supprimée, puis recréée puis de
nouveau supprimée), et que vous utilisiez le nom d’origine, Oracle ressortira de la corbeille la dernière
table supprimée portant ce nom (LIFO : Last In First Out). Pour ressortir spécifiquement une version
plus ancienne, vous pouvez utiliser le nom unique généré par Oracle pour placer la table dans la
corbeille.
Lorsque vous sortez une table de la corbeille, vous pouvez lui attribuer un nouveau nom, ce qui est
pratique si une table portant le même nom existe dans le schéma. Les objets associés sont également
ressortis de la corbeille, mais ils gardent le nom qu’ils avaient dans la corbeille.
L’espace utilisé par les objets stockés dans la corbeille peut être explicitement et définitivement
récupéré grâce à l’ordre SQL PURGE.
Syntaxe
• Purger une table ou un index (avec le nom d’origine ou le nom dans la corbeille, et un principe
FIFO si vous utilisez le nom d’origine et que plusieurs objets portent ce nom)
PURGE { INDEX | TABLE } nom ;
• Purger les tables et les index d’un tablespace, en vous limitant éventuellement aux objets d’un
schéma
PURGE TABLESPACE nom_tablespace [USER nom_utilisateur] ;
• Purger toutes les tables et les index de l’utilisateur courant
PURGE RECYCLEBIN ;
• Purger toutes les tables et les index
PURGE DBA_RECYCLEBIN ;
Vous pouvez noter les restrictions suivantes :
• Les tables supprimées par un DROP TABLESPACE ou un DROP USER ne sont pas placées
dans la corbeille.
• Il n’y a pas de corbeille pour le tablespace SYSTEM.
• Il n’y a pas de corbeille pour les tablespaces gérés par le dictionnaire (uniquement pour les
tablespaces gérés localement).
Exemple
-- je supprime la table
SQL> DROP TABLE diane.adherent;
Table supprimée.
72 | P a g e


-- elle est dans la corbeille (avec ces dépendances)

SQL> SELECT original_name,object_name,type,
2 ts_name,can_undrop,can_purge
3 FROM dba_recyclebin WHERE owner=’DIANE’;
CAN_ CAN_
ORIGINAL_NAME OBJECT_NAME TYPE TS_NAME UNDROP PURGE
-------------- ------------------------------ ------- ------- ----- -----
ADHERENT$PK BIN$y3LFL/MFTs28v7JjGLBSjQ==$0 INDEX INDX NO YES
ADHERENT$UK01 BIN$iDjv77eKRHGEDyAfQ+Hdnw==$0 INDEX INDX NO YES
NUMEROADHERENT BIN$sPGkld1PR3+w2PbWRdhz8A==$0 TRIGGER NO NO
ADHERENT BIN$2tvUDS05RV+Rj2ogvU1aUg==$0 TABLE DATA YES YES
-- il y a bien une table supprimée

SQL> SELECT owner,table_name,dropped FROM dba_tables
2 WHERE table_name=’BIN$2tvUDS05RV+Rj2ogvU1aUg==$0’;
OWNER TABLE_NAME DRO
------------------------------ ------------------------------ ---
DIANE BIN$2tvUDS05RV+Rj2ogvU1aUg==$0 YES
-- et un segment associé
SQL> SELECT segment_name,blocks FROM dba_segments
2 WHERE segment_name=’BIN$2tvUDS05RV+Rj2ogvU1aUg==$0’;
SEGMENT_NAME BLOCKS
------------------------------ ----------
BIN$2tvUDS05RV+Rj2ogvU1aUg==$0 8
-- la table dans la corbeille peut être interrogée

SQL> SELECT COUNT(*) FROM diane."BIN$2tvUDS05RV+Rj2ogvU1aUg==$0";
COUNT(*)
----------
20
-- je ressors la table de la corbeille

SQL> FLASHBACK TABLE diane.adherent TO BEFORE DROP;
Flashback terminé.
-- c’est tout bon

SQL SELECT COUNT(*) FROM diane.adherent;
COUNT(*)
----------
20
-- il faut juste renommer les index (et les triggers)

SQL> SELECT index_name FROM dba_indexes
2 WHERE owner=’DIANE’ AND table_name=’ADHERENT’;
INDEX_NAME
------------------------------
BIN$y3LFL/MFTs28v7JjGLBSjQ==$0
BIN$iDjv77eKRHGEDyAfQ+Hdnw==$0

Une table qui est dans la corbeille peut être interrogée.
4. Niveau base de données
a. Principes
La fonctionnalité de Flashback Database permet de ramener la base de données à l’état où elle était à
un moment donné du passé. Cela équivaut à une récupération incomplète à un instant donné, mais
sans repartir d’une sauvegarde, ce qui est beaucoup plus rapide. Pour pouvoir utiliser cette
73 | P a g e


fonctionnalité, il faut faire fonctionner la base de données dans un mode particulier, le mode
FLASHBACK.
Lorsque la base de données fonctionne dans le mode FLASHBACK, elle génère des fichiers journaux
supplémentaires (flashback log), dans lesquels elle enregistre une copie des blocs modifiés. Ces
fichiers journaux sont obligatoirement stockés dans la zone de récupération rapide (sous-répertoire
nommé flashback).
La durée de conservation des informations dans le fichier journal flashback est définie par le
paramètre d’initialisation DB_FLASHBACK_RETENTION_TARGET (en minutes, 1 440 par défaut,
soit un jour). Comme le nom du paramètre l’indique, la durée de conservation indiquée est un objectif.
S’il n’y a pas suffisamment de place dans la zone de récupération, Oracle réduira la durée de
conservation. Vous devez donc, là encore, dimensionner avec soin la zone de récupération rapide.
Lors d’une opération de flashback vers un instant T dans le passé, les blocs seront restaurés à partir du
fichier journal flashback, à l’état où ils étaient à cet instant ou quelques instants avant ; ensuite, les
fichiers de journalisation seront appliqués. Ceux-ci doivent donc être disponibles et la base de données
fonctionner également dans le mode ARCHIVELOG.
La fonctionnalité de Flashback Database est disponible uniquement en Enterprise Edition.
b. Activer le mode FLASHBACK
Pour >mettre la base de données dans le mode FLASHBACK, vous devez monter la base de données
et exécuter l’ordre SQL ALTER DATABASE FLASHBACK ON :

...
SQL> STARTUP MOUNT
SQL> ALTER DATABASE FLASHBACK ON;
Base de données modifiée.

SQL> SELECT flashback_on FROM v$database;

FLA
---
YES
Par ailleurs, le paramètre DB_FLASHBACK_RETENTION_TARGET peut être modifié

dynamiquement par un ordre SQL ALTER SYSTEM.
La vue V$FLASHBACK_DATABASE_LOG donne des informations sur les journaux flashback :
OLDEST_FLASHBACK_SCN
Numéro SCN le plus ancien dans les journaux flashback.
OLDEST_FLASHBACK_TIME
Date/heure du numéro SCN le plus ancien.
74 | P a g e


RETENTION_TARGET
Durée de conservation objectif, telle que définie par le paramètre

DB_FLASHBACK_RETENTION_TARGET.
FLASHBACK_SIZE
Taille actuelle des données flashback.
ESTIMATED_FLASHBACK_SIZE
Taille estimée des données flashback nécessaire pour la durée de conservation objectif actuellement
définie.
La taille ESTIMATED_FLASHBACK_SIZE est estimée sur la base de l’activité de la base de

données depuis que le mode FLASHBACK a été activé (il faut attendre un peu, avant que cette
colonne soit renseignée).
Si la fenêtre de flashback actuelle, donnée par la valeur de la colonne OLDEST_

FLASHBACK_TIME, est plus courte que la durée objectif, c’est que la zone de récupération rapide
est trop petite et qu’Oracle ne peut pas conserver un historique suffisant (ou que le passage dans le
mode FLASHBACK est récent). Vous devez, dans ce cas, augmenter le quota d’espace alloué à la
zone de récupération rapide (paramètre DB_RECOVERY_ FILE_DEST_SIZE).
Il est possible d’exclure un tablespace du mode FLASHBACK, grâce à la clause FLASHBACK ON |

OFF qui peut être utilisée lors de la création ou de la modification du tablespace (ON par défaut).
c. Procéder à un flashback de la base de données
Vous pouvez utiliser l’ordre SQL FLASHBACK DATABASE ou la commande RMAN

FLASHBACK DATABASE pour procéder à une opération flashback sur la base de données.
Syntaxe
• Ordre SQL
FLASHBACK DATABASE TO [BEFORE] { TIMESTAMP | SCN } expression ;

FLASHBACK DATABASE TO BEFORE RESETLOGS ;
FLASHBACK DATABASE TO RESTORE POINT nom ;
• Commande RMAN
FLASHBACK DATABASE TO [BEFORE] { TIME | SCN | SEQUENCE } [=] expression ;

FLASHBACK DATABASE TO BEFORE RESETLOGS ;
FLASHBACK DATABASE TO RESTORE POINT nom ;
Dans le cas de la commande RMAN, il est possible de préciser un numéro de séquence de fichier de
journalisation comme point de retour ; la base de données est alors, ramenée jusqu’au dernier numéro
SCN enregistré dans le fichier de journalisation (ou le précédent si l’option BEFORE est présente).
Dans les deux cas, la base de données doit être montée (pas ouverte).
75 | P a g e


Ensuite, la base de données doit être ouverte dans le mode RESETLOGS : c’est une nouvelle
incarnation de la base de données.
Exemple dans SQL*Plus

...
SQL> STARTUP MOUNT
...
SQL> FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1/24;

Flashback terminé.
SQL> ALTER DATABASE OPEN RESETLOGS;

Si vous souhaitez vérifier que vous être bien revenu au moment souhaité, vous pouvez ouvrir la base
de données en mode lecture seule :
ALTER DATABASE OPEN READ ONLY;
Si le résultat est satisfaisant, vous pouvez arrêter l’instance, la redémarrer en montant la base de
données, puis ouvrir la base de données avec l’option RESETLOGS. Si le résultat n’est pas
satisfaisant, vous pouvez réaliser un nouveau FLASHBACK DATABASE pour remonter un peu plus
loin en arrière ou un RECOVER DATABASE UNTIL pour aller légèrement en avant.
Si un tablespace a été exclu du mode FLASHBACK, vous devez le passer OFFLINE avant de procéder au
flashback. Ensuite, vous devez supprimer le tablespace ou le récupérer par un moyen traditionnel.
Utiliser le Database Control

1. Configurer les paramètres de récupération
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Paramètres de récupération pour
accéder à la page de configuration des paramètres de récupération.
Cette page comporte plusieurs sections qui permettent :
• De régler la durée de récupération maximale de l’instance (paramètre FAST_START_

MTTR_TARGET) :
76 | P a g e


• De configurer l’archivage des fichiers de journalisation :
• De configurer la zone de récupération rapide et la journalisation pour la fonction de flashback

de la base de données :
77 | P a g e


2. Configurer les paramètres de sauvegarde
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Paramètres de sauvegarde pour
accéder à la page de configuration des paramètres de sauvegarde :
L’onglet Périphérique permet de configurer les périphériques (canaux) par défaut. Le cadre Paramètre
de disque permet notamment de configurer l’emplacement par défaut des sauvegardes (la zone de
78 | P a g e


récupération rapide si rien d’autre n’est indiqué) et le type de sauvegarde par défaut : jeu de
sauvegarde, jeu de sauvegarde compressé ou copie image.
L’onglet Ensemble de sauvegarde permet de configurer les paramètres par défaut des jeux de
sauvegarde, dont la taille maximale d’un élément de sauvegarde.
L’onglet Règle permet :
• De configurer la sauvegarde automatique du fichier de contrôle et du fichier de paramètres

serveur, et d’activer le suivi des blocs modifiés pour les sauvegardes incrémentales :
79 | P a g e


• De configurer la politique de conservation des sauvegardes et de suppression des fichiers de

journalisation archivés :
80 | P a g e


3. Sauvegardes
a. Introduction
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Programmer la sauvegarde pour
accéder à la page de gestion des sauvegardes :
Cette page propose deux possibilités :
• Programmer une sauvegarde proposée par Oracle ;

• Programmer une sauvegarde personnalisée.
b. Stratégie de sauvegarde proposée par Oracle
81 | P a g e


Lorsque vous choisissez l’option Sauvegarde proposée par Oracle, la première page permet de
sélectionner la destination des sauvegardes.
Sur la page suivante, Oracle vous indique la stratégie proposée ; celle-ci peut varier en fonction de la
configuration de la base de données. La stratégie usuelle proposée par Oracle en Enterprise Edition est
basée sur des sauvegardes incrémentales :
• sauvegarde par copie image de la base de données la première fois ;

• sauvegarde incrémentale de niveau 1 ensuite ;
• application régulière des sauvegardes incrémentales à la copie image pour la faire progresser
dans le temps.
La page suivante permet de programmer la sauvegarde.
82 | P a g e


La dernière page donne un récapitulatif de la sauvegarde et montre le script RMAN correspondant.

Vous pouvez cliquer sur le bouton Soumettre le travail si la stratégie proposée par Oracle vous
convient.
c. Stratégie de sauvegarde personnalisée
Lorsque vous choisissez l’option Sauvegarde personnalisée, la première page permet de sélectionner
le type d’objet à sauvegarder (totalité de la base, tablespaces, etc.) et de saisir les informations
d’identification et de connexion à l’hôte.
83 | P a g e


En fonction du type d’objet sélectionné, la page suivante permet de préciser la sélection. Si vous
sélectionnez l’intégralité de la base de données, vous arrivez directement sur la page de choix des
options.
La page Options permet de préciser plusieurs options sur la sauvegarde :
• sauvegarde complète ou sauvegarde incrémentale ;

• sauvegarde en ligne (base ouverte) ou hors ligne (base fermée) ;
• sauvegarde ou non des fichiers de journalisation archivés, etc.
84 | P a g e


La page suivante permet de désigner l’emplacement de la sauvegarde et de modifier les paramètres de

la sauvegarde (bouton Remplacer les paramètres en cours), ceci uniquement pour la sauvegarde en
cours.
La page suivante permet de programmer la sauvegarde (immédiatement ou ultérieurement, répétition,

etc.).
85 | P a g e


La dernière page donne un récapitulatif de la sauvegarde. Vous pouvez cliquer sur le bouton Modifier
le script RMAN pour voir le script RMAN correspondant, et au besoin le modifier. Vous pouvez
cliquer sur le bouton Soumettre le travail pour soumettre ce nouveau travail à l’ordonnanceur
(scheduler).
d. Supervision des sauvegardes
Dernière sauvegarde
Sur la page d’accueil, dans le cadre Haute disponibilité, vous pouvez voir directement la date et
l’heure de la dernière sauvegarde :
Travaux
Sur la page d’accueil, cliquez sur le lien Travaux dans le cadre Liens associés pour afficher la liste des
travaux :
86 | P a g e


Sauvegardes
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Gérer les sauvegardes en cours
pour accéder à la page de gestion des sauvegardes :
Cette page permet de rechercher des sauvegardes et de réaliser différentes actions :
• cataloguer des fichiers non connus du référentiel RMAN (bouton Ecrire des fichiers
supplémentaires dans le catalogue) ;
• vérifier la cohérence entre le référentiel RMAN et les fichiers physiques (bouton Tout contre-
vérifier) ;
• supprimer les sauvegardes obsolètes (bouton Supprimer tous les éléments obsolètes) ;
• supprimer tous les objets ayant le statut EXPIRED (bouton Supprimer tous les éléments
arrivés à expiration).
87 | P a g e


4. Récupération
a. Démarrer une récupération
Si la base de données n’est pas ouverte, vous accédez à l’assistant récupération, grâce au bouton
Effectuer la récupération qui est proposé sur la page donnant le statut de la base de données :
Après saisie des informations d’’identification et de connexion à l’hôte puis à la base de données
(connexion SYSDBA), vous accédez à la page de récupération (voir ci-dessous).
Si la base de données est ouverte, vous accédez à l’assistant récupération en cliquant sur le lien
Disponibilité puis sur le lien Effectuer la récupération.
Si un échec sur un fichier a été détecté, Oracle déclenche une alerte critique dans la catégorie "Echec
de données". Ces alertes peuvent être visualisées dans le cadre Alertes de la page d’accueil :
88 | P a g e


b. L’assistant de récupération
Les informations affichées en haut de la page dépendent de la nature du problème. Sur l’exemple ci-
dessus, un échec a été détecté mais la base de données est ouverte. Si la base de données est fermée,
l’affichage le mentionne. Exemple :
Si vous ouvrez cette page alors qu’il n’y a aucun problème, aucune information n’est affichée en haut.
Normalement, en cas de problème, des informations de diagnostic provenant du Data Recovery

Advisor sont affichées et le bouton Conseiller et récupérer est actif ; vous pouvez cliquer ce bouton
pour effectuer la récupération à l’aide du Data Recovery Advisor (cf. Exemple de récupération avec le
Data Recovery Advisor). C’est la méthode la plus simple pour effectuer la récupération.
Si le problème n’est pas considéré comme un échec par le Data Recovery Advisor, des informations
de diagnostic sont quand même affichées en haut de la page, mais le bouton Conseiller et récupérer est
inactif :
89 | P a g e


Dans ce cas, en cliquant dans l’ordre sur les liens affichés, le Database Control vous guide pour
effectuer la récupération (cf. Exemple de récupération ordonnée par l’utilisateur).
Si vous souhaitez effectuer une récupération alors qu’aucun problème n’a été détecté par Oracle (par
exemple pour revenir avant un ordre SQL malencontreux), ou si vous souhaitez résoudre un problème
avec votre propre stratégie, vous pouvez démarrer une récupération dite "ordonnée par l’utilisateur" :
Pour cela, vous devez sélectionner l’étendue de la récupération et un type d’opération, puis cliquer sur
le bouton Récupérer (cf. Exemple de récupération ordonnée par l’utilisateur).
Avant de démarrer la récupération avec une des méthodes présentées ci‐dessus, vérifiez que des
informations d’identification et de connexion à l’hôte sont correctement saisies dans le bas de la page.
c. Exemple de récupération avec le Data Recovery Advisor
Vous pouvez accéder à la page du Data Recovery Advisor de différentes manières :
• en cliquant sur le bouton Conseiller et récupérer de la page de récupération ;

• en cliquant sur le lien Data Recovery Advisor du centre de conseil ;
• en cliquant sur le bouton Lancer Recovery Advisor des pages de résultat de l’exécution des
outils de vérification (cf. Chapitre Les outils d’administration section Diagnostiquer les
problèmes).
90 | P a g e


Cette page affiche les échecs détectés par le Data Recovery Advisor. Par défaut, seuls les échecs de
statut OPEN et de priorité CRITICAL ou HIGH sont affichés ; vous pouvez utiliser le petit formulaire
de recherche pour filtrer les échecs affichés.
Un clic sur le bouton Conseil permet d’afficher les conseils de résolution pour les échecs sélectionnés
dans la liste.
Le conseiller commence par afficher les actions manuelles qui peuvent être réalisées pour effectuer la
récupération :
Pour afficher les actions de récupération automatique identifiées par le Data Recovery Advisor, vous
pouvez cliquer sur le bouton Poursuivre avec les conseils.
91 | P a g e


Pour exécuter les actions de récupération automatique identifiées par le Data Recovery Advisor, vous
pouvez cliquer sur le bouton Continuer.
Cliquez sur le bouton Soumettre le travail de récupération pour lancer la récupération.
Si la base de données est ouverte, le Data Recovery Advisor lance le travail de récupération et vous
rend la main :
92 | P a g e


Vous pouvez retrouver ce travail en cliquant sur le lien Travaux (cadre Liens associés situé dans le bas
de la page d’accueil de chaque onglet).
Si la base de données est fermée, le Data Recovery Advisor attend que le travail se termine puis
affiche le résultat :
À ce stade, deux cas se présentent en général :
La base de données était montée (pas de problème avec les fichiers de contrôle)
Si la récupération a réussi, un bouton Ouvrir la base de données est présent et il ne reste plus qu’à
cliquer sur ce bouton pour ouvrir la base de données.
La base de données n’était pas montée (problème avec les fichiers de contrôle)
Si la récupération a réussi, la base de données est montée mais le Data Recovery Advisor ne sait pas
encore si elle peut être ouverte ; le bouton Ouvrir la base de données n’est pas présent.
Si vous cliquez sur le bouton OK, vous revenez sur la page de statut de la base de données et vous
pouvez de nouveau cliquer sur le bouton Effectuer la récupération pour revenir sur la page de
récupération.
S’il n’y a plus d’échec de fichier, la page se présente ainsi :
93 | P a g e


Pour ouvrir la base de données, cliquez sur le lien Instance de base de données pour revenir à la page
de statut, puis sur le bouton Démarrer (cf. section Démarrage du chapitre Démarrage et arrêt).
S’il y a des échecs de fichier, la page se présente ainsi et une nouvelle opération de récupération est
nécessaire :
Parfois les informations du Data Recovery Advisor ne s’affichent pas correctement ; cliquer sur le lien Statut
en cours résout, généralement, ce problème. Vous pouvez aussi cliquer sur le lien Echecs de base de données
pour afficher la page du Data Recovery Advisor.
d. Exemple de récupération ordonnée par l’utilisateur
Pour illustrer le fonctionnement de l’assistant, nous allons prendre le cas d’une récupération d’un
fichier de données :
1. Cliquez sur le bouton Récupérer.
94 | P a g e


La page suivante permet de sélectionner les fichiers de données à récupérer (bouton Ajouter) ; les
fichiers endommagés détectés par Oracle sont proposés par défaut dans la liste.
La page suivante permet d’indiquer s’il faut restaurer les fichiers de données à leur emplacement
d’origine ou ailleurs.
95 | P a g e


La dernière page donne un récapitulatif de la récupération. Vous pouvez cliquer sur le bouton
Modifier le script RMAN pour voir le script RMAN correspondant, et au besoin le modifier. Vous
pouvez cliquer sur le bouton Soumettre pour lancer l’opération. L’opération n’est pas lancée sous la
forme d’un travail détaché ; vous restez sur la page tout le temps de l’opération, sans aucune
information sur son degré d’avancement.
Lorsque l’opération est terminée, le rapport RMAN est affiché.
e. Flashback
Base de données
L’assistant vous permet de faire une récupération de toute la base de données jusqu’à l’heure en cours
ou jusqu’à un point antérieur dans le temps (base montée uniquement) :
Dans ce cas, si la journalisation flashback est active sur votre base de données, Oracle vous indique
qu’il peut utiliser la fonctionnalité de flashback de la base de données, si l’heure de retour demandée
est compatible avec les journaux. Cliquez sur le bouton Récupérer et laissez-vous guider.
Table
Parmi les types d’objets d’une récupération, vous pouvez choisir « Tables » :
96 | P a g e


Dans ce cas, Oracle vous propose de faire un flashback soit pour ramener la table dans un état
antérieur, soit pour annuler la suppression d’une table. Là encore, cliquez sur le bouton Récupérer et
laissez-vous guider.
Ligne
Les fonctionnalités de flashback de niveau ligne, mais aussi de niveau table, sont accessibles à partir
de la page de gestion des tables, via les menus Interrogation de versions Flashback et Table
Flashback :
97 | P a g e

Chapitre 13 Sauvegarde Et Récupération

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Chapitre 13 Sauvegarde Et Récupération

Загружено:

Авторское право:

Доступные форматы

Support de Cours ORACLE 11g : Administration, par Mawunya Koffi GBENOU

Chapitre 13 : Sauvegarde et récupération

Cette sécurité est assurée par :

• la mise en œuvre d’une protection des fichiers sensibles de la base :

Les questions à se poser pour définir la stratégie sont les suivantes :

• Est-il acceptable de perdre des données ?

Il est également nécessaire de déterminer la nature de l’activité sur la base :

Le principe de récupération en mode ARCHIVELOG est le suivant :

Une sauvegarde peut être cohérente ou incohérente.

Le tableau suivant résume les possiblités :

Pertes de données acceptables

• Aucune perte de donnée n’est autorisée.

Le mode NOARCHIVELOG est possible si :

• Des pertes de données sont acceptables.

Archivage des fichiers de journalisation

Le mode opératoire est le suivant :

SQL> ALTER SYSTEM SET

• Arrêter proprement la base de données (pas ABORT)

SQL> SHUTDOWN IMMEDIATE

• Monter la base de données

SQL> STARTUP MOUNT

• Passer la base de données en mode ARCHIVELOG

SQL> ALTER DATABASE ARCHIVELOG;

• Sauvegarder la base de données (permet une sauvegarde T0 du nouveau mode de

SQL> ALTER DATABASE OPEN;

L’ordre SQL ALTER DATABASE NOARCHIVELOGpermet, au besoin, de repasser en mode

Ce paramètre définit le format souhaité pour le nom des archives.

Le format doit inclure les variables suivantes :

Numéro de séquence du fichier de journalisation.

Numéro d’instance (thread).

Identifiant de remise à zéro des fichiers de journalisation (voir la section Récupération).

Le paramètre LOG_ARCHIVE_DEST définit une première destination de l’archivage et le paramètre

Les paramètres LOG_ARCHIVE_DEST_n permettent de spécifier plusieurs destinations parallèles

D’autres paramètres permettent de piloter le fonctionnement des destinations multiples (destinations

ARCHIVE_LAG_TARGET = 1800 # 30 minutes

S’il n’y a rien à archiver, Oracle ne génère pas d’archive.

SQL> CONNECT / AS SYSDBA

• V$DATABASE : mode de fonctionnement de la base de données (colonne LOG_MODE) ;>

• V$LOG : statut des groupes vis-à-vis de l’archivage (colonne ARCHIVED) ;<

Les colonnes intéressantes de la vue V$ARCHIVED_LOG sont les suivantes :

Chemin complet de l’archive.

Numéro de séquence du fichier de journalisation correspondant.

Plus petit numéro SCN écrit dans l’archive.

Date et heure du plus petit numéro SCN.

Plus grand numéro SCN écrit dans l’archive.

Date et heure du plus grand numéro SCN.

Date et heure de l’archivage.

Les colonnes intéressantes de la vue V$ARCHIVE_DEST sont les suivantes :

Statut de la destination (VALID, ERROR, etc.).

Message d’erreur (en cas d’erreur).

SQL> SELECT log_mode FROM v$database;

SQL> SELECT group#,sequence#,status,archived

SQL> SELECT sequence#,name FROM v$archived_log;

L’archivage peut être bloqué lorsqu’il y a un problème avec la destination d’archivage :

• plus d’espace disponible ;

Sun Aug 3 12:43:25 2008

ALTER SYSTEM SET

Présentation du Recovery Manager

Les options suivantes peuvent être utilisées :

TARGET [=] connexion

Chaîne de connexion à la base de données cible.

CATALOG [=] connexion

Chaîne de connexion à la base de données du catalogue de récupération.