1. Pour assurer la fiabilité de la base:
On va voire les différentes pannes provoquant le système et les différentes méthodes physique et logique de Sauvegarde, restauration et journalisation de données pour éviter le plus que possible ces pannes.
Type de pannes :
Erreur accidentelle: suppression de tables ou d'autres objets; de telles erreurs peuvent être évitées grâce aux dispositifs de confidentialité d'Oracle et à des contrôles stricts au niveau des programmes utilisateurs.
Panne sur une commande SQL: en présence d'un problème d'allocation d'extensions ou autres, Oracle renvoie un code d'erreur et annule les commandes de cette transaction pour rétablir la cohérence de la base de données
Panne d'un processus: si un processus s'arrête brutalement sans avoir validé ou annulé les transactions en cours, le processus PMON détecte cet état, se connecte automatiquement sur le compte disparu pour valider ou annuler la transaction et libérer les ressources (verrous) détenues par ce processus.
Panne d'instance: une panne matériel ou logiciel peut empêcher une base Oracle de continuer à fonctionner. La base s'arrête dans un état incohérent: certaines modifications validées n'ont pas encore été transmises aux fichiers de données mais existent sur les journaux de reprise; inversement certaines modifications non validées ont déja été transmises aux fichiers de données (mais leur image avant existe dans le segments Rollback). Au démarrage, Oracle détecte automatiquement que l'arrêt précédent ne provient pas d'une fermeture (shutdown) propre et le processus SMON effectue le "Roll-forward" de l'ensemble des modifications présentes dans les journaux de reprise, suivi de l'annulation des transactions non validées.
Panne disque: une cause matériel peut empêcher de lire et d'écrire sur les fichiers concernés par les transactions en cours. Le cas le plus fréquent est l'erreur I/O sur l'un des fichiers de la base (données, reprise, contrôle) ; une restauration appropriée dépend du type de fichier perdu.
Les opérations d'Oracle après une panne affectant le journal de reprise ou le fichier de contrôle dépendent de la présence de fichiers miroir. En présence d'un miroir du fichier reprise en ligne endommagé, Oracle continue à fonctionner sans interruption; dans le cas contraire, les opérations d'Oracle s'arrêtent et peuvent provoquer des pertes de données.
Oracle s'arrête si le fichier Control est endommagé, qu'il y ait fichier miroir ou non.
Les pannes sur fichier de données se situent à deux niveaux:
-Oracle détecte une erreur de lecture sur un fichier de données, un code d'erreur est renvoyé à l'utilisateur et Oracle continue à fonctionner
-Oracle détecte une erreur d'écriture : si le fichier de reprise en ligne plein est archivé, une erreur est retournée par le fichier de trace et le tablespace endommagé est mis automatiquement offline; si le fichier de reprise en ligne plein n'est pas archivé, le processus DBWR s'arrête et l'instance se bloque.
1.1 La sauvegarde ,restauration et journalisation :
Une des plus importantes tâches de l'administrateur de la base de données est la planification et la mise en place des procédures de sauvegarde et de restauration de la base. Cette planification est guidée par plusieurs critères:
- est-il acceptable de perdre des données et, si oui, dans quelles limites?
- la base doit-elle être accessible en permanence?
- quel est le délai acceptable de restauration au niveau de l'utilisation de la base?
- quelle est la fréquence d'évolution des données?
- les modifications physiques de la base sont-elles nombreuses?
1.1.1 La sauvegarde :
Stratégies de sauvegarde :
La stratégie de sauvegarde est fonction des deux critères suivants:
- Acceptabilité: Peut-on accepter de perdre des données en cas de panne?
Si la réponse est non, la base doit opérer obligatoirement en mode ARCHIVELOG pour sauvegarder les journaux de reprise pleins.
Si la réponse est oui, la base pourra opérer en mode NOARCHIVELOG et la fréquence des sauvegardes dépendra de la tolérance de perte (1 jour ou 1 semaine par exemple).
- Disponibilité: Quelle est la durée de panne tolérée?
Une base fortement disponible fonctionnera en mode ARCHIVELOG. Les journaux de reprise en ligne pleins sont archivés automatiquement ou manuellement; couplés avec les journaux en ligne, ils permettront un recouvrement complet de la base jusqu'au moment de la panne.
| | | Acceptabilité des pertes | ||
| | | Une journée | Quelques heures | Aucune |
| | 1 fois par jour | BACKUP ou EXPORT | BACKUP/jour config REDOLOGS | BACKUP online & ARCHIVELOG |
| Fréquence d’arrêt | 1 fois par semaine | BACKUP/semaine + EXPORT/jour | BACKUP/semaine + EXPORT/jour config REDOLOGS | BACKUP online & ARCHIVELOG |
| | Jamais | EXPORT/jour | BACKUP online & ARCHIVELOG | BACKUP online & ARCHIVELOG |
| |
| |
Ø Les utilitaires import/export :
Avant tout il faut préciser que cette méthode est une méthode logique de sauvegarde (Export) et de restauration des données (Import). Elle va nous permettre de sauvegarder le contenu logique d'une base de données dans un fichier de transfert Oracle au format binaire, ou fichier dump. Ce fichier pourra donc être relu pour recréer des objets qu'il contient. Ce transfert peut s'accomplir sur une même base ou même sur deux bases Oracle, et cela même si leurs configurations matérielles et logicielles diffèrent. Cela signifie que l'on peut tout à fait exporter une base sous Windows pour l'importer sous Linux ou Unix (sauf pour les tablespaces transportables).
Ces deux utilitaires qui peuvent être alors employés comme des techniques de sauvegarde peuvent être exécutées à partir de n'importe quel client NET*8, le fichier DUMP est traité, dans ce cas, de manière locale par rapport au client : lors d'un import ou d'un export à partir d'un client NET*8, il faut faire attention car cette opération peut augmenter le trafic du réseau et affecter ce dernier de manière importante. Autre précision de taille : la version de l'utilitaire Import ne peut être antérieure à celle de l'utilitaire Export, plus précisément on ne saurait exporter une base de données Oracle 9i pour l'importer sur une base de données 8i avec leur utilitaire d'origine. Et enfin dernier détail mais non des moindres, ne compressez jamais un fichier dump avec un outil de compression système Winzip (Windows) ou GZIP (Linux - Unix), vous risqueriez d'avoir de mauvaises surprises lors de sa décompression.
Privilèges pré-requis :
| Actions | Privilège ou rôle nécessaire |
| Exporter son propre schéma | CREATE SESSION |
| Exporter d'autres schémas | SYSDBA, EXP_FULL_DATABASE et DBA |
| Exporter la base entière ou tablespaces | EXP_FULL_DATABASE |
| Importer un objet du fichier DUMP | IMP_FULL_DATABASE |
Les différents modes d'export et d'import :
a. Niveau base de données complète :
C'est le mode le plus complet, lors de ce type d'exportation tous les objets de la base sont exportés à l'exception de certains utilisateurs : SYS, ORDSYS, CTXSYS, MDSYS et ORDPLUGINS. Par contre les informations relatives aux structures de base de données, telles que les définitions de tablespaces et de segments de rollback, sont incluses. Lors de L'insertion des données tout ces objets sont importés et créés dans la base de destination : le paramètre FULL permet de spécifier ce mode pour l'exportation et l'importation.
| Export FULL des objets : |
| C:\> exp userid=system/manager file=c:\backup\export_full.dump log=c:\control\export_full.log full=y rows=y |
Ici, on se connecte à la base en tant que SYSTEM (userid=system/manager) et on exporte toute la base (full=y) avec les données (rows=y). On sauvegarde la sortie dans le fichier de log (log=c:\control\export_full.log).
| Import de tous les schémas inclus dans le DUMP : |
| C:\> imp userid=system/manager file=c:\backup\export_full.dump log=c:\control\export_full.log |
b. Niveau utilisateur :
Dans ce cas là, ce sont tous les objets appartenant à un utilisateur qui sont exportés: tables, fonctions, synonymes, déclencheurs, liens de bases de données… Le paramètre OWNER permet de désigner les utilisateurs que l'on désire exporter et le paramètre FROMUSER désigne quel est l'utilisateur à importer du fichier Dump (le paramètre TOUSER nous indique quand à lui le schéma destinataire).
| Export du schéma SCOTT : |
| C:\> exp userid=system/manager file=c:\backup\export_full.dump log=c:\control\export_full.log owner=scott |
| Import du schéma SCOTT : |
| C:\> imp userid=scott/tiger file=c:\backup\export_full.dump log=c:\control\export_full.log owner=scott |
| Import du schéma SCOTT dans le schéma TEST : |
| C:\> imp userid=system/manager file=c:\backup\export_full.dump log=c:\control\export_full.log fromuser=scott touser=test |
c. Niveau table :
Lors de l'exportation de tables individuelles tous leurs objets associés (index, contraintes, déclencheurs, privilèges …) sont écrits dans le fichier DUMP. Lors de l'importation tout comme l'exportation les tables doivent être nommées grâce au paramètre TABLES.
| Export de la table ACCOUNT de l'utilisateur SCOTT : |
| C:\> exp userid=system/manager file=c:\backup\export_full.dump log=c:\control\export_full.log tables=scott.account |
| Import de la table ACCOUNT de l'utilisateur SCOTT dans TEST : |
| C:\> imp userid=system/manager file=c:\backup\export_full.dump log=c:\control\export_full.log fromuser=scott touser=test tables=scott.account |
d. Niveau tablespace :
Lors de l'exportation, des métas donnés concernant les tablespaces spécifiés et les objets qu'ils contiennent sont écrites dans un fichier DUMP.
| Export du tablespace USER : | ||
| C:\> exp userid=system/manager file=c:\backup\export_full.dump log=c:\control\export_full.log tablespaces=user | ||
|
| Paramètre | Description | Valeur par défaut |
| Userid | chaîne de connexion à la base de données | |
| Buffer | Taille du buffer de transfert | 4096 |
| Compress | Compression des extents en un seul | Y |
| Contraints | Export des contraintes | Y |
| File | Nom du fichier DUMP | expdat.dmp |
| Log | Nom du fichier de sortie du compte-rendu, pour voir les erreurs en particulier | |
| Full | Export de toute la base | N |
| Grants | Export des privilèges | Y |
| Help | Affiche la liste des paramètres supportés, aucun DUMP généré. | N |
| Indexes | Export des index | Y |
| Owner | Utilisateur(s) à exporter | userid |
| Parfile | Fichier contenant les paramètres d'export | |
| Recordlength | Taille des enregistrements (migration SE) | |
| Record | Indique que l'export doit stocker les informations sur les exports et les objets exportés | Y |
| Inctype | Export incrémental (COMPLETE, CUMULATIVE, INCREMENTAL) | |
| Rows | Export des lignes | |
| Query | Définit une condition de filtre pour exporter un sous-ensemble | |
| Tables | Table(s) à exporter | |
| Consistent | Positionne sa session en " READ ONLY " le temps de l'export. Cela permet donc de préserver la cohérence des données exportées. | N |
| Direct | Chargement direct par tableau | N |
| Statistics | Analyse des objets exportés | ESTIMATE |
| Feedback | Affiche la progression de l'export tous les n enregistrements | N |
| Point_in_time_Recover | Indique si on autorise l'export des tablespaces | N |
| Recover_Tablespaces | Liste des tablespaces à sauvegarder | |
| Volsize | Nombre d'octets à écrire sur chaque volume bande | |
Paramètres d'export :
Paramètres d'import
| Paramètre | Description | Valeur par défaut |
| Userid | chaîne de connexion à la base de données | |
| Buffer | Taille du buffer de transfert | 10240 |
| Commit | Ecriture régulière des blocs de données | N |
| File | Nom du fichier DUMP | expdat.dmp |
| Log | Nom du fichier de sortie du compte-rendu, pour voir les erreurs en particulier | |
| Fromuser | Utilisateur à exporter vers TOUSER | |
| Full | Import de tout le contenu du DUMP | N |
| Grants | Export des privilèges | Y |
| Help | Affiche la liste des paramètres supportés, aucun DUMP généré. | N |
| Ignore | Ignore les erreurs et continue l'import | N |
| Indexes | Import des index | Y |
| Parfile | Fichier contenant les paramètres d'import | |
| Recordlength | Taille des enregistrements (migration SE) | |
| Rows | Import des données | Y |
| Destroy | Détruit les objets s'ils existent avant de les importer | N |
| Show | Liste le contenu du fichier d'export, | N |
| Tables | Table(s) à importer | |
| Touser | Utilisateur destinataire | |
| Charset | Code alphabet du pays de référence s'il est différent de celui de la création de base | NLS_LANG |
| Point_in_time_recover | Indique si on autorise l'import des tablespaces | N |
| Skip_unusable_indexes | Permet de repousser la reconstruction de l'index après l'insertion des données dont ils dépendent | N |
| Analyze | Exécute la commande ANALYZE dans le fichier dump | Y |
| Feedback | Affiche la progression de l'import tous les n enregistrements | 0 |
| Volsize | Nombre d'octets dans le fichier pour chaque volume bande | |
Automatiser l’export a l’aide d’un fichier .BAT: Voici le contenue du fichier bat :( Il faut l l’adapter comme vous voulez)
| echo off cls echo ------------------------------------------------------- SET fic_sauv=sauvegarde__%date:~0,2%_%date:~3,2%_%date:~6,4%.dmp SET dir_sauv=sauvegarde__%date:~0,2%_%date:~3,2%_%date:~6,4% SET log_sauv=log__%date:~0,2%_%date:~3,2%_%date:~6,4%.log SET racine_sauv = C:\ echo ------------------------------------------------------- echo ****************************************************************************** echo **************************** Starting .... ************************************ echo************************************************************************** IF NOT EXIST %racine_sauv%essais\%dir_sauv% mkdir %racine_sauv%essais\%dir_sauv% EXP.EXE userid=TEST/TEST file=%racine_sauv%essais\%dir_sauv%\%fic_sauv% log=%racine_sauv%essais\%dir_sauv%\%log_sauv% echo************************************************************************** echo *******************************End************************************** echo************************************************************************** pause |
Une sauvegarde à froid 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.
Nous allons donc vous fournir un exemple de script pour automatiser le processus :
Nous allons donc vous fournir un exemple de script pour automatiser le processus :
Le script suivant permet de sauver les fichiers de la base de données sous Windows. Il génère le script de sauvegarde des fichiers (datafiles, logfiles, controlfile et tempfile) qui copie ces fichiers dans le répertoire défini par la variable repertoire.
-- Variables d'environnement de SQL*Plus de formatage de l'affichage Set feedback off Set Linesize 200 Set Heading off Set Pagesize 0 Set Trimspool off Set Verify off define repertoire ='c:\archive' -- il faut créer ce répertoire de destination des fichiers sauvegardés define fichier_control=c:\control_backup.sql -- définition du fichier de sortie spool &fichier_controlselect 'host copy ' || name || ' &repertoire ' from v$datafile order by 1 ; select 'host copy ' || member || ' &repertoire ' from v$logfile order by 1 ; select 'host copy ' || name || ' &repertoire ' from v$controlfile order by 1 ; select 'host copy ' || name || ' &repertoire ' from v$tempfile order by 1 ; spool off -- Fermeture de la base de données pour avoir des fichiers synchronisés shutdown immediate @&fichier_controlstartup |
Nous allons expliquer par la suite comment restaurer les données modifiées entre la dernière sauvegarde à froid et un instant choisi.
Ø sauvegarde online (sauvegarde à chaud "Hot backup"):
Comme nous venons de le voir, effectuer une restauration ou récupération d'une base de données implique que la base soit arrêtée, cependant dans des environnements à haute disponibilité cela est parfois impossible. Une solution dans ce cas existe: "Hot backup" ou sauvegarde à chaud. Le problème est le suivant, dans le cas d'une haute disponibilité, forcément l'état des fichiers change constamment : des modifications sont apportés dans les fichiers de données, des informations de contrôle sont écrites dans les fichiers de contrôle, et des informations de reprise sont consignées dans les fichiers REDO, lesquels peuvent également être archivés. Pour effectuer une sauvegarde dans ce cas, la solution est de placer chaque tablespace dans le mode de sauvegarde et de sauvegarder les fichiers de données, puis de rétablir le tablespace dans le mode normal. On sauvegarde donc des fichiers incohérents puisque les SCN, contenus dans les entêtes de fichiers de données sont différents. Il faudra effectuer une récupération de support pour rendre ces différents SCN cohérents et pouvoir ouvrir la base.
Etant donné que les changements qui ont lieu durant la phase de sauvegarde d'un tablespace donnent lieu à une consignation dans le flux de reprise, la base doit être en mode ARCHIVELOG.
Les tablespaces en mode lecture seule (" alter tablespace tools read only ") ne peuvent pas être sauvegardé car la base ne peut pas les modifier, pas plus que ceux gérés localement. Dans ce cas là, la solution consiste à les recréer.
Etant donné que les changements qui ont lieu durant la phase de sauvegarde d'un tablespace donnent lieu à une consignation dans le flux de reprise, la base doit être en mode ARCHIVELOG.
Les tablespaces en mode lecture seule (" alter tablespace tools read only ") ne peuvent pas être sauvegardé car la base ne peut pas les modifier, pas plus que ceux gérés localement. Dans ce cas là, la solution consiste à les recréer.
1.1.2 La journalisation :
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.
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.
Si la base n'est pas en mode ARCHIVELOG alors il faut modifier le fichier d'initiatisation de la base (init<SID>.ora), et ajouter ou modifier les paramètres suivantes :
|
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 :
| NB : 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 |
1.1.3 La restauration :
Les buffers Database sont écrits sur disque uniquement lorsque c’est nécessaire, en utilisant l’algorithme LRU (Last Recently Used); les fichiers de données pevent ainsi contenir des blocs de données modifiées par des transactions non validées et ne pas contenir des blocs de données modifiées par des transactions validées (ces données modifiées sont contenues dans le journal de reprise)
Pour résoudre ces problèmes, Oracle réalise la restauration de la base en deux étapes:
-la première étape d’un recouvrement consiste à appliquer aux fichiers de données « l’image avant » du journal de reprise (roll-forward); cette opération consiste à enregistrer toutes les modifications contenues dans des journaux en ligne et archivés sur les fichiers de données et sur les rollback segments. Après cette opération, les fichiers de données contiennent toutes les modifications, validées ou non.
-la seconde étape consiste à appliquer sur les fichiers de données « l’image arrière » à partir des rollback segments; cette étape annule l’action des transactions non validées.
Recouvrement après une panne d’instance :
Le recouvrement d’une instance restaure la base dans l’état cohérent qu’elle possédait juste avant la panne. Le noyau Oracle exécute automatiquement les étapes suivantes:
-déroulement de l’image avant « Roll Forward »
-déroulement de l’image après « Roll Back »
-libération des ressources et des verrous maintenus par la transaction au moment de la panne
Les actions à réaliser par l’administrateur sont:
-fermer la base avec l’option Normal (SHUTDOWN NORMAL)
-ouvrir la base avec STARTUP
Recouvrement après une panne disque :
Le mode de recouvrement après panne disque dépend du mode d’archivage dans lequel opérait la base avant la production de la panne.
En mode NOARCHIVELOG, les journaux de reprise pleins sont réutilisés sans être archivés. Le recouvrement consiste alors en une restauration de la sauvegarde complète la plus récente; les modifications réalisées après cette dernière sauvegarde sont alors perdues.
| Type de fichier perdu | Mode d’Archivage | ||||
| Data | Redolog on line | Archive | Control file | ARCHIVELOG | NOARCHIVELOG |
| X | | | | Effectuer une restauration du fichier | Réappliquer un Backup à froid |
| | X | | | Reconstruire les fichiers perdus suivant le type de configuration | |
| | | X | | Refaire un backup de la base | Sans incidence |
| | | | X | Utiliser un fichier de contrôle miroir | |
| X | | X | | Restauration incomplète | Réappliquer un backup à froid |
En mode ARCHIVELOG, le recouvrement peut permettre de restaurer la base jusqu’à la dernière transaction validée, juste avant la production de la panne.
Plusieurs cas de figure peuvent alors se présenter selon les types de fichiers perdus et selon la disponibilité souhaitée de la base au moment du recouvrement.
Recouvrement complet :
ü En cas de Base de données fermée :
-la base ne peut être ouverte en mode normal
-un ou plusieurs fichiers de données du tablespace SYSTEM sont endommagés
-un fichier de données contenant les rollback segments est endommagé
Il faut alors :
-réparer ou changer le disque
-restaurer la sauvegarde la plus récente des fichiers endommagés
-se connecter comme INTERNAL
-démarrer une nouvelle instance sans ouvrir la base (STARTUP NOMOUNT)
-renommer et localiser les fichiers de données s’ils ne sont pas restaurés à l’endroit d’origine
-activer tous les fichiers de données avec la commande
ALTER DATABASE DATAFILE nom_fich ONLINE
-soit démarrer le recouvrement de toute la base par la commande RECOVER DATABASE soit démarrer le recouvrement d’un fichier endommagé par RECOVER DATAFILE
-ouvrir la base avec la commande ALTER DATABASE nom_base OPEN
ü En cas de Base de données ouverte :
-la base peut être ouverte en mode normal
-les fichiers du tablespace SYSTEM ou contenant les rollback segments ne sont pas endommagés
- des fichiers de données sont endommagés
Il faut alors :
-désactiver les tablespaces endommagés
-réparer ou changer le disque
-restaurer les fichiers endommagés
-renommer et localiser les fichiers de données s’ils ne sont pas restaurés à l’endroit d’origine
-exécuter le recouvrement des tablespaces endommagés par les commandes RECOVER TABLESPACE ou RECOVER DATAFILE
-le noyau Oracle applique les journaux de reprise archivés et en ligne pour produire l’image avant « Roll Forward »
-les tablespaces endommagés sont restaurés et peuvent être mis en ligne par la commande ALTER TABLESPACE nom_tablespace ONLINE
Fichier de contrôle endommagé :
Le recouvrement peut être complet si la sauvegarde du fichier de contrôle reflète la structure de la base au moment de la panne. Sinon, il faut recréer les fichiers de contrôle à l'aide de la commande :
| CREATE CONTROLFILE DATABASE database_name LOGFILE …………………………………………… DATAFILE …………………………………………… ; |
Recouvrement incomplet :
Le recouvrement incomplet peut être utilisé dans les cas suivants:
-annuler des opérations jusqu’à un point donné
-plusieurs groupes de journaux sont endommagés et ne peuvent être appliqués au recouvrement
-recouvrement à un point donné dans le passé
-suite à une perte accidentelle d’une table, pouvoir utiliser un recouvrement à certain moment
-un journal de reprise en ligne peut être indisponible à cause d’une panne système; les entrées journaux qui sont écrites sur les fichiers de données sont valides, les autres ne le sont ps; une partie de ce journal peut être utilisée pour un recouvrement allant à une période T par exemple.
Il faut alors :
-fermer la base avec l’option ABORT
-démarrer une nouvelle instance avec l’option MOUNT
-mettre tous les fichiers de données en ligne
ALTER TABLSPACE DATAFILE nom_fich ONLINE
- exécuter une des procédures de recouvrement suivantes:
RECOVER DATABASE UNTIL CANCEL
RECOVER DATABASE UNTIL TIME date
RECOVER DATABASE UNTIL CHANGE entier
En cas d’utilisation d’une sauvegarde d’un fichier de contrôle, l’option USING BACKUP CONTROLFILE doit être spécifiée.