LA SAUVEGARDE ET

RESTAURATION DE
LA BASE DE DONNEES ORACLE
Essalmani Yasmine
Sarah Aggour
Kenza Belhaj Soulami
Meryem Ait Ouakrim

LA SAUVEGARDE

ROLE DU DBA

S'assurer que la base Augmenter le temps

de données ne perde moyen sans pannes
pas de données MTBF

Prise en compte des Réduire la durée

besoins de d'indisponibilité suite
l'entreprise et des à une panne
performances MTTR


CATEGORIES DE PANNES

1 Echec d'instruction

2 Echec processus utilisateur

3 Panne de réseau

4 Erreur utilisateur

5 Echec support

6 Echec de l'instance
ECHEC D'INSTRUCTION
Le premier niveau de fixation sera automatique : Chaque fois qu'une instruction échoue, le
processus serveur qui exécute l'instruction détectera le problème et annulera l'instruction.

Une cause courante d'échec d'instruction est une donnée non valide, généralement un
format ou une contrainte violation.

Une deuxième classe d'échecs d'instructions non liés à DBA est constituée d'erreurs logiques
dans l'application : du code qui, dans certaines circonstances, est impossible pour la base de
données à exécuter.

Les instructions peuvent échouer en raison de privilèges insuffisants.

Les problèmes de gestion de l'espace sont fréquents, mais ils ne devraient jamais se
produire.


ECHEC DU PROCESSUS
UTILISATEUR

Sortie anormale Erreur du

Session terminée
de l'utilisateur au programme qui
de façon
lieu de se met fin à la
anormale
déconnecter session


PANNE RESEAU
Configuration de
plusieurs listners, chacun
Panne de listner
sur une combinaison
adresse/port différente

Idéalement, avoir au moins

Panne carte deux cartes réseau, pour la
réseau redondance ainsi que les
performances


ERREURS UTILISATEUR
La requête Flashback implique l'exécution d'une requête sur une version de la base de
données au quelque temps dans le passé. La version cohérente en lecture de la base de
données est construite, par votre session uniquement, grâce à l'utilisation de données
d'annulation.

La récupération incomplète et la base de données de flashback sont des techniques

beaucoup plus drastiques pour
annuler les erreurs de l'utilisateur.

Si un flashback est effectué de toute la base de données, vous perdrez tout le travail
précédemment effectué après l'heure à laquelle la base de données a été renvoyée, et pas
seulement la mauvaise transaction.


ECHEC DU SUPPORT
Archivelog sont initialement créés sur disque et, en raison des risques liés à l'utilisation du
stockage sur disque, tout comme le fichier de contrôle et les fichiers en ligne de
journalisation, doivent être multiplexés : deux ou plus copies sur différents appareils.

Ainsi, pour vous protéger contre les pannes de support, vous devez disposer de copies
multiplexées du controlfile, les fichiers de journalisation en ligne et les fichiers de
journalisation d'archivage.
Ne pas sauvegarder les redo logs — ils sont, en effet, sauvegardés lorsqu'ils sont copiés dans
les archive log.

Les fichiers de données ne peuvent pas être protégés par multiplexage ; ils doivent être
protégés par du matériel : redondance - soit des systèmes RAID conventionnels, soit le
propre système de stockage automatique d'Oracle Gestion (ASM).


ECHEC INSTANCE
Arrêt ou au
Problèmes
Coupure de redémarrage du
matériels
courant machine serveur
critiques

Après un échec d'instance, la base de données peut manquer des transactions validées
et stocker les transactions non validées.

Cette situation se produit car les processus serveur fonctionnent en mémoire : ils mettent à
jour des blocs de données et annulent des segments dans le cache du tampon de la base de
données, et non sur le disque. DBWn écrit ensuite les blocs modifiés dans les fichiers de
données.


RECUPERATION INSTANCE

Si la base de données est corrompue, c'est-à-dire qu'il contient des données non validées ou
qu'il manque des données validées, Oracle détecte l'incohérence et effectue une récupération
d'instance pour supprimer les corruptions.

Il rétablira toutes les transactions validées qui n'ont pas été enregistrées dans les fichiers de
données à moment du plantage et annuler toutes les transactions non validées qui avaient été
écrites aux fichiers de données.

Utiliser le contenu des fichiers journaux en ligne pour reconstruire la base de données cache de
tampons à l'état dans lequel il se trouvait avant le crash.
RECUPERATION INSTANCE
1 2 3
STARTUP Récupération Base de donnée
d'instance peut être ouverte
ROLL FORWARD mais toujours
corrompue

4
Réstauration des
transactions non
validées
PRÉPARATION DE LA BASE DE
DONNÉES POUR LA
RÉCUPÉRABILITÉ

1 2 3 4
Fichiers de Online Redo-log Mode archive-log Fichiers journaux
contrôle d'archivage


1
Fichiers de
contrôle
Le fichier de contrôle est petit mais vital. Il est utilisé pour monter la base de données, et tandis
que la base de données est ouverte, le fichier de contrôle est continuellement lu et écrit.

Avoir au moins deux copies du fichier de contrôle, sur des supports physiques différents.

Oracle s'assure que toutes les copies du fichier de contrôle sont identiques, il suffit donc de
copier un fichier de contrôle survivant sur le fichier endommagé ou manque un.

Mais les dommages causés à un fichier de contrôle entraînent des temps d'arrêt. L'instant où
Oracle détecte qu'un fichier de contrôle est endommagé ou manquant, l'instance se terminera
immédiatement en cas d'échec de l'instance.


2
Online Redo-log

Une base de données Oracle nécessite au moins deux groupes de fichiers journaux en ligne
pour fonction, afin qu'il puisse basculer entre eux.

Chaque groupe est composé d'un ou plusieurs membres, qui sont les fichiers physiques. Un seul
membre par groupe est requis pour Oracle pour fonctionner, mais au moins deux membres par
groupe sont nécessaires pour la sécurité.

La seule chose qu'un DBA n'est pas autorisé à faire est de perdre toutes les copies du
groupe de fichiers journaux en ligne. Si cela se produit, vous perdrez des données.


3
Mode archive-log

Les fichiers de journalisation en ligne sont écrasés lorsque les changements de journal se produisent ; le passage à
le mode archivelog garantit qu'aucun groupe de fichiers de journalisation en ligne n'est écrasé à moins qu'il n'ait
a d'abord été copié en tant que fichier journal d'archivage. Ainsi, il y aura une série de fichiers journaux d'archives
qui représentent un historique complet de toutes les modifications jamais appliquées à la base de données. Si un fichier
de données est endommagé à tout moment, il sera alors possible de restaurer une sauvegarde du fichier de données et
appliquez les modifications du flux de rétablissement du journal d'archivage pour le mettre à jour.
Par défaut, une base de données est créée en mode noarchivelog ; cela signifie qu'en ligne
les fichiers de journalisation sont écrasés par les commutateurs de journalisation sans qu'aucune copie ne soit effectuée
au préalable. Il est encore
impossible de corrompre la base de données, mais des données pourraient être perdues si les fichiers de données sont
endommagés
par défaillance des médias. Une fois la base de données passée en mode archivelog, il est impossible
perdre des données également, à condition que tous les fichiers journaux d'archivage générés depuis la dernière
sauvegarde sont disponibles.
Une sauvegarde est une copie de vos données qui peut être utilisée pour
reconstruire le contenu de votre base de données originale.

La sauvegarde doit être effectuée sur des disques différents de vos

disques de données d'origine pour éviter la perte de données ainsi que les
sauvegardes en cas de panne du disque dur.

Dans le contexte d’Oracle, il existe deux principaux types de sauvegarde :

la sauvegarde physique et la sauvegarde logique.
 SAUVEGARDE
Logique
Export/import utility
Exporte les données logiques telles que
les procédures stockées ,table,
tablespace, schémas …à partir d'une
base de données avec un utilitaire
d'exportation Oracle et stockées dans
un fichier binaire
Physique
La sauvegarde physique est une
sauvegarde des fichiers physiques
utilisés pour stocker et restaurer
votre base de données. Tels que les
fichiers de données, les fichiers de
contrôle, et les redo logs archivés.

 MODES DE
SAUVEGARDE

sauvegarde a chaud
sauvegarde a froid
sauvegarde RMAN
 Hot backup

Pour effectuer une restauration ou récupération d'une base de données

il faud que la base soit arrêtée, cependant dans des environnements à
haute disponibilité cela est parfois impossible. Une solution dans ce cas
est la sauvegarde à chaud.

Sauvegarde incohérente
Sauvegarde pendant que la base de données est opérationnelle
Aucun temps d'arrêt requis
La base de données doit être en mode journal d'archivage pour effectuer une sauvegarde à
chaud
Nous devons sauvegarder tous les journaux d'archivage à partir du moment de la sauvegarde
pour récupérer la base de données
Avantages:

*il minimise les temps d'arrêt au quotidien, ce qui est particulièrement utile pour les systèmes qui
nécessitent un fonctionnement 24h/24 et 7j/7.

Inconvénient :

*Le problème avec les sauvegardes à chaud est que si les données sont modifiées pendant la
sauvegarde, il peut y avoir des incohérences, telles que l'état précédent du fichier inclus dans la
sauvegarde plutôt que le dernier.

* Les sauvegardes à chaud consomment également des ressources informatiques, de sorte que les
performances de la machine et du serveur peuvent être affectées pendant les sauvegardes.
 Exécution d'une sauvegarde à chaud :

La base de données doit être opérationnelle

Aucun temps d'arrêt requis
Mettez la base de données en mode de démarrage de sauvegarde
modifier la base de données commencer la sauvegarde ;
sélectionner un statut distinct de vSbackup
Copiez tous les fichiers au niveau du système d'exploitation vers l'emplacement de sauvegarde à chaud
Mettez la base de données en mode de sauvegarde de fin
modifier la sauvegarde de fin de base de données ;
sélectionnez le statut du district à partir de v$backup ;
Changer le fichier journal
modifier le fichier journal du commutateur système ;
'Prendre la sauvegarde des journaux d'archives
 Cold backup

Une sauvegarde à froid « offline backups « signifie qu'un arrêt de la base

de données est effectué. Lorsque la base est arrêtée, l'activité est
interrompue et les fichiers peuvent alors être copiés sans corruption de
données.

Sauvegarde entièrement cohérente

Effectué lorsque la base de données est fermée
Nécessite un temps d'arrêt
L'utilisateur ne peut pas accéder à la base de données
Pas besoin de sauvegarder les journaux redo ou d'archiver les journaux
Une sauvegarde à froid est effectuée à l'aide de la commande Copier au niveau
du système d'exploitation
En temps réel, nous effectuons rarement une sauvegarde à froid
Avantages:
*la sauvegarde ne peut pas être affectée par des virus actifs ou des tentatives de piratage.
*Ils ne seront pas affectés par les surtensions, ce qui en fait le moyen le plus fiable de
sauvegarder vos données.

lInconvénients
*pendant ce temps, aucun utilisateur ne peut accéder au système.
*La récupération après un sinistre avec des sauvegardes à froid peut également prendre plus de
temps, car le déplacement des données du site de sauvegarde à froid peut entraîner des retards.
 Exécution d'une sauvegarde à froid :

Trouver l'emplacement de tous les fichiers physiques

Arrêt de la base de données (option IMMÉDIAT ou NORMAL) :
Utilisez les commandes ou les utilitaires du système d'exploitation pour copier les fichiers de données
de la base de données et les fichiers de contrôle vers votre destination de sauvegarde :
Remarque 1 :Assurez-vous que cette destination de sauvegarde dispose de suffisamment d'espace
Remarque 2 : Si vous utilisez n'importe quelle saveur Unix, utilisez la commande cp
Démarrez la base de données.
Vérifiez votre sauvegarde.
En conclusion, les sauvegardes à chaud doivent être utilisées lorsque
les temps d'arrêt doivent être aussi faibles que possible et les
sauvegardes à froid doivent être utilisées lorsqu'aucun utilisateur n'a
accès au système.
RMAN backup

Les types de fichiers pouvant être sauvegardés par RMAN sont

1 Datafiles

2 Controlfile

3 Archive redo log files

4 SPFILE

5 Backup set pieces

 Types de sauvegarde
Complète
consiste à sauvegarder sur un
support tous les fichiers de la base
(data file, log file, control file)
Etapes:
• fermer la DB avec l'option
NORMAL,
• sauvegarder tous les fichiers de la
base
Cumilative Differentielle
on sauvegarde uniquement on sauvegarde uniquement les
les blocs modifiés depuis la blocs modifiés depuis la
précédente sauvegarde de précédente sauvegarde de
niveau n-1. niveau n ou inférieur
• dès l'instant où un fichier a été
modifié, il sera toujours inclu
 RMAN gère trois niveaux de sauvegardes incrémentielles :

Niveau 0 : base de tous les autres niveaux (Sauvegarde de l'ensemble des blocs
contenant des données) ;
Niveau 1 : sauvegarde tous les blocs qui ont changé depuis la plus récente sauvegarde
incrémentielle de niveau 0 ;
Niveau 2 : sauvegarde tous les blocs qui ont changé depuis la plus récente sauvegarde
incrémentielle de niveau 0, 1 ou 2.
 Differentielle

Cumilative
 Terminologie

Base de données cible : on appelle base de données cible la base qui est l'objet d'opérations de
sauvegarde/restauration, RMAN utilise les fichiers de contrôle de la base cible afin de récupérer les
informations sur les objets à sauvegarder.

BackupPiece : c'est une entité physique contenant un ou plusieurs fichiers de données. Un fichier
peut très bien être sur plusieurs backup pieces. Leur nombre et leur taille dépendent du paramètre
maxpiecesize.

BackupSet : c'est une entité logique contenant un ou plusieurs backup pieces. Il est impossible d'avoir
un fichier sur plusieurs backup sets (librairies). Il est impossible de mixer dans une même librairie des
fichiers de contrôle et des fichiers d'archive.
Principe de stockage des sauvegardes :

Les utilisaters qui peuvent utiliser RMAN

SYSDBA
SYSOPER
SYSBACKUP
 Mode d'accès RMAN

Connexion à RMAN avec un catalogue de récupération

$ rman target u1/p1[@aliastarget] catalog u2/p2[@aliascatalog]

Connexion à RMAN sans catalogue de récupération

$ rman target u1/p1[@aliastarget] nocatalog

Options de lancement de la commande RMAN

On lance un script RMAN stocké sur un système de fichiers à l'aide de l'option
cmdfile.

 RMAN et les unités de sauvegarde

RMAN peut envoyer des sauvegardes sur bande à l'aide d'un media manager (MM) tel que
arcserve, backupexec ou time navigator par exemple. Le MM est un outil de sauvegarde
externe
Il comprend:
MML : une simple bibliothèque qui interprète les requêtes issues de RMAN et qui les traduit
en requêtes compréhensibles pour le MM client
MM Client: partie du logiciel qui fait la connexion avec le MM serve
MMServeur
 MISE EN OEUVRE DE RMAN
Préparation de l'environnement OS

ORACLE_SID : nom de l'instance ;

ORACLE_HOME : répertoire d'installation du produit Oracle ;
PATH : doit contenir le répertoire des binaires Oracle soit $ORACLE_HOME/bin ;
LD_LIBRARY_PATH (sur Solaris et Digital Unix) (SHLIB_PATH sur HP-UX -
LIBPATH sur AIX), il doit contenir le répertoire des librairies Oracle soit
$ORACLE_HOME/lib ;
NLS_LANG si le jeu de caractères (characterset) de la base n'est pas celui par
défaut de l'OS.
Création du catalogue RMAN
1-Création d'un utilisateur propriétaire du catalogue

SQL>create tablespace rman_ts_data datafile '/files1/RMAN/rman_ts_data01.dbf'

size 50M ;

Tablespace Created

SQL>create user rman identified by rmanpwd default tablespace RMAN_TS_DATA;

User created.

SQL>grant connect, resource, recovery_catalog_owner to rman;

Grant succeeded.
 1-Création du catalogue

Il faut se connecter à la base Oracle (dans laquelle le schéma a été créé

précédemment) à l'aide de la commande rman :
 Première sauvegarde de base de données avec RMAN

1. Déclaration de la base de données cible dans le catalogue RMAN

Enregistrement sous RMAN de la base de données cible

Le plus simple est souvent de se

connecter sur la machine cible sans
mot de passe et de taper :
 Sauvegarde de la base de données

Le script donné ci-dessous est donné à titre d'exemple et permet de faire une sauvegarde FULL d'une
base en mode ARCHIVELOG sur disque.


RESTAURATION

PLAN

Restauration des fichiers de données

Restauration totale de la base de
données
1. Définition du mode ARCHIVELOG
2. Activation du mode ARCHIVELOG
3. Restauration compléte à partir de la sauvegarde à froid
4. Restauration partielle à partir de la sauvegarde à froid
RESTAURATION DES FICHIERS
DE DONNÉES

La restauration de la base de données est

particulièrement simple, elle est réalisée
par les étapes suivantes :
Arrêt de la base de données
Suppression des datafiles, logfiles,
controlfiles et tempfiles
Restauration des fichiers
Démarrage de la base de données
Si la sauvegarde à froid s'est bien
déroulée alors le démarrage suite à la
restauration des fichiers ne doit poser
aucun problème.
RESTAURATION TOTALE
DE LA BASE DE DONNÉES

Restaurer la base de données à

l'instant de la sauvegarde peut être
salutaire mais c'est souvent
insuffisant, la perte des données
devant être la plus petite possible.
Afin de récupérer le maximum de
données il convient donc de passer
la base de données en mode
ARCHIVELOG
DÉFINITION DU MODE ARCHIVELOG
LORSQUE DES OPÉRATIONS SONT EXÉCUTÉES DANS LA BASE, DES ENTRÉES DE REPRISE DÉCRIVANT
LES MODIFICATIONS APPORTÉES AUX DONNÉES SONT CONSIGNÉES DANS LES FICHIERS REDO
APRÈS ÊTRE PASSÉES PAR LE TAMPON REDO. CHAQUE BASE DOIT AU MOINS CONTENIR DEUX
FICHIERS REDO EN LIGNE (GÉNÉRALEMENT ELLE EN COMPTE TROIS).LA RAISON PRINCIPALE EST
QUE LORSQU'UN FICHIER REDO EST PLEIN LA BASE DOIT POUVOIR CONTINUER DE CONSIGNER LES
DESCRIPTIONS DES CHANGEMENTS QUI INTERVIENNENT. POUR EMPÊCHER D'ÉCRASER
IMMÉDIATEMENT LES ENTRÉES DU FICHIER EN COURS, LA BASE POURSUIT LA CONSIGNATION DES
MODIFICATIONS DANS L'AUTRE FICHIER. CETTE PHASE S'APPELLE UNE COMMUTATION DE JOURNAL
(LOG SWITCH).
VOUS POUVEZ DEMANDER À ORACLE DE CONSIGNER CES FICHIERS ET DONC ÉVITER LORS DE LA
FIN D'UN CYCLE QU'ILS NE SOIENT ÉCRASÉS. ORACLE LES COPIE DONC VERS UN OU PLUSIEURS
EMPLACEMENTS HORS LIGNE... CETTE PROCÉDURE S'APPELLE L'ARCHIVAGE DU JOURNAL DE
REPRISE (ASSURÉE PAR LE PROCESSUS ARCH). ELLE PERMET DE PRODUIRE UN JEU DE FICHIERS REDO
ARCHIVÉS. CETTE OPTION DOIT ÊTRE ACTIVÉE ET PARAMÉTRÉE POUR POUVOIR RÉCUPÉRER
TOUTES LES MODIFICATIONS.
ACTIVATION DU
MODE
ARCHIVELOG
Tout d'abord vérifiez que la base n'est pas déjà
en mode ARCHIVELOG.
Oracle SQL*Plus

Base de données modifiée.

SQL> select name, log_mode from v$database;

NAME LOG_MODE

--------- -----------
BD0 NOARCHIVELOG

SQL> ¦

Si la base n'est pas en mode ARCHIVELOG alors il faut

modifier le fichier d'initiatisation de la base (init<SID>.ora)
Désormais, le paramétrage de la base est suffisant pour accepter
le passage en mode ARCHIVELOG. Il convient donc de monter la
base, positionner le mode ARCHIVELOG et ouvrir la base. C'est ce
qu'illustre la figure suivante :
# UNCOMMENTING THE LINE BELOW WILL CAUSE AUTOMATIC ARCHIVING IF ARCHIVING HAS
# BEEN ENABLED USING ALTER DATABASE ARCHIVELOG

# PERMISSION D'UTILISER LE MODE ARCHIVELOG

LOG_ARCHIVE_START = TRUE
# DESTINATION DES ARCHIVES DE REDO
LOG_ARCHIVE_DEST_1 = "LOCATION=C:\ORACLE\ORADATA\BD0\ARCHIVE"
LOG_ARCHIVE_DEST_2 = "LOCATION=C:\TEMP"
# FORMAT DE FICHIER DES ARCHIVES
LOG_ARCHIVE_FORMAT = %%ORACLE_SID%%T%TS%S.ARC


SQL> startup mount

Instance ORACLE Lancée.

Total System Global Area 78284828 bytes

Fixed Size 75804 bytes
Variable Size 56922112 bytes
Database Buffers 21209088 bytes
Redo Buffers 77824 bytes
Base de données montée
SQL> alter database archivelog;

Base de données modifiée.

SQL> alter database open;
Base de données modifiée.
SQL> select name, log_mode from v$database;
NAME LOG_MODE
----------- ------------------
BD0 ARCHIVELOG

SQL>
La commande alter database open peut ne pas
s'exécuter si vous êtes sous Oracle 9i, pour ce faire,
arrêtez de nouveau la base (shutdown immediate)
puis redémarrez grâce à la commande : STARTUP
 SELECT NAME, VALUEFROM
V$PARAMETERSWHERE NAME LIKE
'LOG_ARCHIVE%';

PROMPT VEUILLEZ DEFINIR UN REPERTOIRE DE DESTINATION

ACCEPT &REPERTOIRE_ARCHIVAGE
PROMPT VEUILLEZ DEFINIR UN FICHIER DE SORTIE
ACCEPT &FICHIER
PROMPT ARCHIVELOG NEXT ;;
SELECT ' COPY ' || NAME || ' &REPERTOIRE_ARCHIVAGE ' FROM V$ARCHIVED_LOG
WHERE COMPLETION_TIME >= TRUNC (SYSDATE) -1 AND COMPLETION_TIME < TRUNC(SYSDATE) ;
RESTAURATION COMPLÉTE À PARTIR
DE LA SAUVEGARDE À FROID
Je vous propose un cas pratique pour
illustrer le modus operandi de cette
restauration. Imaginons la perte du
datafilec:\oracle\oradata\BD0\users01.db
f. La perte d'un datafile provoque
immédiatement l'erreur suivante et arrête
la base de données :

ORA-01157: impossible d'identifier ou de

verrouiller le fichier de données 3 -
voir le fichier de trace DBWR
ORA-01110: fichier de données 3
:'C:\ORACLE\ORADATA\BD0\USERS01.DB
F'
La première étape consiste alors à restaurer le fichier de notre
dernière sauvegarde complète (la vue v$recover_files permet
de retrouver le(s) fichier(s) à restaurer). Une fois que le fichier
est à nouveau disponible il faut le resynchroniser. C'est à dire
qu'il faut rejouer les redos jusqu'à ce que les données soient
complètement restaurées et que le numéro SCN du
tablespace corresponde au numéro SCN des autres
tablespaces de la base de données.
Ensuite on démarre la base en prenant soin de lancer un
RECOVER :

SQL> STARTUP MOUNT;

SQL> RECOVER DATABASE

media recovery completed

SQL> ALTER DATABASE OPEN;

 RESTAURATION
PARTIELLE À PARTIR DE
LA SAUVEGARDE À
FROID

La restauration peut aussi être réalisée

partiellement: PITR, Point in time
recovery. Cela permet de repositionner
la base de données à un point donné
défini par un numéro SCN ou une date
et heure. Nous prendrons comme
exemple, la suppression du tablespace
INDX par erreur.


Sun Nov 02 19:59:26 2003

Thread 1 advanced to log sequence 19.
Current log#1 seq# 19 mem# 0:C :/ORACLE/ORADATA/BD0.LOG
SUN NOV 02 19:59:26 2003
ARC0:Beginning to archive log# 3 seq# 18
ARC0:Completed archiving log# 3 seq# 18
SUN NOV 02 20:16:38 2003
drop table space indx

SUN NOV 02 20:16:40 2003

Completed:drop table space indx
SUN NOV 02 20:25:36 2003
Thread 1 advanced to log sequence 20
Dans ce fichier on peut voir que la suppression
du tablespace a eu lieu le 02/11/2003 à
20:16:26 et que le dernier numéro de séquence
est 19. Pour récupérer la situation la plus
cohérente possible, nous allons restaurer
jusqu'au numéro SCN de cette séquence.

SQL> SELECT sequence# as

sequence,first_change# as SCN FROM
v$log_history
WHERE sequence#=19

SEQUENCE SCN
--------------------- ----------19
383077
Lançons maintenant la récupération (RECOVER DATABASE)
en indiquant le SCN 383077 trouvé précédemment :

SQL> STARTUP MOUNT;

SQL> RECOVER DATABASE AUTOMATIC UNTIL SCN 383077;
SQL> ALTER DATABASE OPEN RESETLOGS;
L'option AUTOMATIC évite de devoir donner l'emplacement des archivelogs, et RESETLOGS
réinitialise la séquence de redologs à 1.
Lorsqu'on ouvre une base avec cette option, tous les fichiers de données et REDO archivés reçoivent
un nouveau SCN et une horodate de réinitialisation. Ce qui empêche de corrompre des fichiers de
données avec d'anciens fichiers archivés en s'assurant que les valeurs du SCN et de l'horodate de
réinitialisation sont cohérentes avec le fichier REDO. Cette commande peut prendre un certain
temps avant de s'exécuter, car tout les fichiers REDO en ligne sont reconstruits, chaque entête de
fichiers de donnée est modifié, et les fichiers de contrôle sont mis à jour. Une nouvelle sauvegarde
cohérente est conseillé dans ce cas la.
Il est également possible de donner l'heure à laquelle on veut se positionner plutôt que le SCN. Dans
ce cas on exécutera :

SQL> STARTUP MOUNT;

SQL> RECOVER DATABASE AUTOMATIC UNTIL TIME '2003-11-02 20:16:20';
SQL> ALTER DATABASE OPEN RESETLOGS;
Enfin, il est possible d'indiquer une récupération
de toutes les archives jusqu'à ce que l'une d'elle
soit introuvable. Les fichiers REDO sont donc
appliqués un par un jusqu'à atteindre le fichier
sur lequel on désire s'arrêter. Dans l'exemple
suivant on utilise les fichiers de contrôle.
SQL> STARTUP MOUNT;
SQL> RECOVER DATABASE AUTOMATIC UNTIL CANCEL
USING BACKUP CONTROL FILE;
SQL> ALTER DATABASE OPEN RESETLOGS;
Cette récupération peut s'avérer nécessaire lorsqu'un fichier REDO est
manquant. En effet Oracle détermine dans les fichiers archivés et en ligne les
fichiers nécessaires et s'arrête lorsqu'il ne trouve pas le suivant (pensez que le
redo courant n'est pas pris en compte, il faut donc bien l'indiquer). Ici nous
allons interagir avec la procédure de restauration, en effet à la fin de chaque
fichier REDO appliqué, la procédure nous demande de continuer ou d'arrêter.
Ici la base est redémarrée est le fichier des alertes doit confirmer la
récupération en indiquant par exemple :

Mon Nov 03 12:20:35 2003

RESETLOGS after complete recovery trought change 383077

LA COMMANDE RECOVER
OFFRE D'AUTRES POSSIBILITÉS
DONT VOICI QUELQUES
EXEMPLES :
-- Récupération un fichier spécifique désigné par son
nom
SQL > recover datafile
'c:\oracle\oradata\bd0\user01.dbf' ;
-- Récupération un fichier spécifique désigné par son
identifiant
SQL > recover from 'e:\archived_log' datafile 5 ;
-- Récupération du tablespace
USERSSQL > recover from 'e:\archived_log' tablespace
USERS ;
-- Récupération de plusieurs fichiers désignés par leur
nom
SQL > recover from 'e:\archived_log'datafile
'c:\oracle\oradata\bd0\user01.dbf',
'c:\oracle\oradata\bd0\user02.dbf' ;
MERCI POUR VOTRE
ATTENTION