 |
|
|
|
|
|
|
|
| |
| |
| |
Technique |
|
Domaines |
|
Divers | |
Contact | |
Restauration partielle (incomplète)
Dans certains cas, il peut être nécessaire de restaurer la base dans un état cohérent, mais jusqu’à un moment précis, antérieure à la panne ou à l'erreur fatale (suppression de lignes, drop d’une table, etc. ...). Tous les types de restaurations partielles se font base fermée. Il s'agit de demander à Oracle de reconstituer une base cohérente à un moment antérieur à celui de l'incident qui a provoqué le besoin de restauration. ORACLE offre trois méthodes de restauration partielle. Le choix du type de restauration se fait en fonction des informations dont on dispose pour déterminer la fin de la restauration : un numéro de fichier journal, une heure ou un numéro de SCN (System Change Number).
Les étapes suivantes sont nécessaires à une restauration incomplète :
- Si la base tourne toujours, arrêt de la base en mode ABORT.
SVRMGR> shutdown abort
- Si on dispose de temps et de place, il est prudent de faire une sauvegarde complète pour se prémunir des fausses manœuvres de la restauration.
- Récupération par des commandes du système d'exploitation de tous les fichiers de données et des fichiers de contrôle pour revenir à un état correspondant à un moment antérieur à celui qu'on veut restaurer.
- Démarrage de la base sans l'ouvrir.
SVRMGR> startup mount nom_de_la_base
- Changement des noms des fichiers déplacés, s'il y a lieu.
SVRMGR> alter database rename file 'ancien_nom' to 'nouveau_nom'; # pour chacun des fichiers modifiés
- Mise en ligne de tous les fichiers de données. (Cette étape n'est pas nécessaire dans le cas d'une restauration terminée par CANCEL).
SVRMGR> alter database datafile 'nom_fichier' online;
- Restauration. Cette étape varie en fonction du type de restauration. Les paragraphes suivants détaillent chaque type.
- Ouverture de la base de données avec réinitialisation des fichiers journaux.
SVRMGR> alter database open resetlogs;
La réinitialisation des fichiers journaux est nécessaire car Oracle ne peut pas gérer des "trous" de numérotation dans ses fichiers journaux. Cette réinitialisation vide les fichiers journaux actifs, et recommence la numérotation des fichiers journaux à 1. Aucune restauration (des fichiers plus vétustes que RESETLOGS) n'est possible après cette opération.
- Sauvegarde complète de la base de données.
L'étape précédente ayant entraîné l'impossibilité de faire une nouvelle restauration, cette étape relève de la plus élémentaire prudence...
- Archivage sur bande ou dans un autre répertoire des anciens fichiers journaux archivés. Cette étape est rendue nécessaire par la nouvelle numérotation des fichiers journaux.
Restauration terminée par CANCEL
Cette méthode est utilisée lors de la restauration de base avec perte de fichiers journaux, qu'ils soient 'en ligne' ou archivés. La commande doit être tapée avant d'atteindre les transactions concernant le fichier perdu ou endommagé. La restauration terminée par CANCEL se lance par la commande suivante :
SVRMGR> recover database until cancel;Code 88 Recover database until cancel
Avant d'appliquer un fichier journal, Oracle demande confirmation. Pour terminer la restauration, il suffit de répondre CANCEL. (l'opérateur tape la commande 'CANCEL' durant la restauration pour indiquer à ORACLE que le processus doit s'arrêter).
Restauration basée sur une heure
Oracle terminera automatiquement la restauration lorsqu'il aura atteint l'heure spécifiée. Toutes les transactions commencées avant cette heure mais validées plus tard sont annulées. La restauration basée sur une heure se lance par les commandes suivantes :
SVRMGR> set autorecovery on # Oracle ne demandera pas confirmation pour
# chacun des fichiers journaux à appliquer
SVRMGR> recover database until time 'YYYY-MM-DD:HH24:MI:SS';
Code 89 Recover database until time
Restauration basée sur un SCN
ORACLE effectue une restauration jusqu'à atteindre un numéro de validation (SCN) donné. Oracle terminera automatiquement la restauration lorsqu'il aura atteint le numéro de SCN spécifié. La restauration basée sur un SCN (System Change Number) se lance par les commandes suivantes :
SVRMGR> set autorecovery on # Oracle ne demandera pas confirmation pour
# chacun des fichiers journaux à appliquer
SVRMGR> recover database until change numero_SCN;
Code 90 Recover database until change
Réinitialisation des fichiers journaux
Il est possible de réinitialiser les fichiers journaux après une restauration complète ou non de la base. La commande ALTER DATABASE RESETLOGS effectue les actions suivantes :
- Annule toutes les transactions des fichiers journaux qui n'ont pas été appliquées durant la restauration.
- Réinitialise le numéro de séquence du fichier de contrôle à 1.
- Vide le fichier journal courant.
- Crée le fichier journal courant s'il n'existe pas.
- Réinitialise le numéro de séquence des fichiers journaux à 1 dans tous les en-têtes des fichiers.
NORESETLOGS ou RESETLOGS ?
Quand doit-on utiliser la commande ALTER DATABASE OPEN NORESETLOGS ou ALTER DATABASE OPEN RESETLOGS ?
- Si une sauvegarde du fichier de contrôle a été utilisée, réinitialiser le numéro de fichier journal.
- Dans le cas d'une restauration incomplète (vérifier le message dans le fichier d'ALERT), réinitialiser le numéro de fichier journal.
- Dans le cas d'une restauration complète sans utilisation de sauvegarde de fichier de contrôle, ne pas réinitialiser le numéro de fichier journal. Si les numéros de séquence doivent être réinitialisés, fermer la base et effectuer une sauvegarde OS.
| Copyright © 1998-2002 Radu Caulea, TAFORA | MAJ 06/11/2006 |  |
| Commentaires et suggestions radu[CHEZ]tafora.fr | ||