Sauvegarde et restauration de données sous Oracle 9iDate de publication : 31/05/2005 , Date de mise à jour : 26/09/2005
Par
Jaouad (jaouad.developpez.com) Présentation des méthodes de sauvegarde et restauration proposées par Oracle 9i 1. LES UTILITAIRES EXPORT ET IMPORT 1.1. Introduction 1.2. Les différents modes d'export et d'import 1.2.a. Niveau base de données complète 1.2.b. Niveau utilisateur 1.2.c. Niveau table 1.2.d. Niveau tablespace 1.2.e. Privilèges pré-requis 1.3. Les principaux paramètres de contrôle 1.3.a. Paramètres d'export 1.3.b. Paramètres d'import 1.4. Deux façons d'exporter et d'importer 1.4.a. En ligne de commande 1.4.b. En utilisant un fichier de paramètres 1.5. Exporter selon une condition 2. SAUVEGARDE A FROID 2.1. Introduction 2.2. Sauvegarde 3. SAUVEGARDE A CHAUD 3.1. Introduction 3.2. Sauvegarde 4. RESTAURATION DES DONNEES 4.1. Restauration des fichiers de données 4.2. Restauration totale de la base de données 4.2.a. Définition du mode ARCHIVELOG 4.2.b. Activation du mode ARCHIVELOG 4.2.c. Restauration compléte à partir de la sauvegarde à froid 4.2.d. Restauration partielle à partir de la sauvegarde à froid 5. DUPLICATION D'UNE BASE DE DONNEES 5.1. Introduction 5.2. Préparation à la création d'une base de données clone 5.3. Fichier d'initialisation 5.4. Fichier de mots de passe 5.5. Création de services sous Windows 5.6. Sauvegarde de la base de donnée source 5.7. Préparer le script de création du fichier de contrôle 5.8. Récupération de la base de données 5.9. Démarrage de la base de données 6. BASE DE SECOURS : STANDBY DATABASE 6.1. Introduction 6.2. Création d'une base de secours 6.3. Sauvegarde à chaud de la base de secours 6.4. Configurer le fichier de paramètre de la base de secours 6.5. Monter la base de secours 6.6. Récupération automatique 6.6.a. Configuration des services NET*8 6.6.b. Mode de récupération 6.6.c. Configuration de la base principale 6.7. Activer la base de secours 7. UTILISATION DU LOGMINER 7.1. Introduction 7.2. Installation du LOGMINER 7.2.a. Paramètres pré-requis 7.2.b. Création du fichier de dictionnaire 7.2.c. Spécifier les fichiers LOG à analyser 7.2.d. Lancer l'analyse 7.2.e. La vue V$LOGNMR_CONTENTS 8. Annulation d'un ordre DML 9. Bibliographie Remerciement 1. LES UTILITAIRES EXPORT ET IMPORT1.1. Introduction
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és à 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. 1.2. Les différents modes d'export et d'import1.2.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.
1.2.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).
1.2.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.
1.2.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.
1.2.e. Privilèges pré-requis
1.3. Les principaux paramètres de contrôle1.3.a. Paramètres d'export
1.3.b. Paramètres d'import
1.4. Deux façons d'exporter et d'importer1.4.a. En ligne de commande
Ici, on se connecte à la base en tant que SYSTEM (userid=system/manager) et on exporte
toute la base (full=y) sans les données (rows=n). On sauvegarde la sortie dans le
fichier de log (log=c:\control\export_full.log). Voici quelques exemples suplémentaires :
Les exemples suivants permettent d'importer les fichiers générés dans les exemples précédents.
1.4.b. En utilisant un fichier de paramètres
Nous avons pu voir dans les exemples précédents que la ligne de commande peut devenir
très fastidieuse à écrire. Afin de faciliter la maintenance des scripts, les utilitaires d'export et import
permettent d'indiquer un fichier de paramètres via l'option parfile. Ainsi ce fichier est simplement l'énumération des paramètres à appliquer. Avec le fichier c:\backup\parfile.prm suivant :
Les commandes suivantes sont équivalentes :
1.5. Exporter selon une condition
Depuis la version 8i , il est possible de n'exporter qu'une partie de la table et non pas la totalité. Il suffit de le préciser par l'option QUERY. Dans cette exemple nous allons exporter les personnes dont le salaire est supérieur à 500, dropper la table et enfin la réimporter.
On souhaite donc avoir un fichier qui contient les données correspondant à la requête suivante :
La commande d'export sera alors la suivante :
Il y a bien 6 lignes exportées. Vérifions que les données sont bien les bonnes.
Voila une option très utile pour rafraichir un jeu de test par exemple.
2. SAUVEGARDE A FROID2.1. Introduction
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 et vous expliquer comment restaurer les données modifiées entre la dernière sauvegarde à froid et un instant choisi. 2.2. Sauvegarde
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. Il devra être adapté selon vos chemins personnels et surtout l'OS (copy sera remplacé par cp pour Unix par exemple).
3. SAUVEGARDE A CHAUD3.1. Introduction
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. 3.2. Sauvegarde
Tout d'abord nous allons commencer par créer un script de sauvegarde à chaud de la base de données. Ce script que nous appellerons
sauvegarde_chaud.sql nous aidera dans le traitement des tablespaces et des fichiers de données.
Le script précédant doit générer et exécuter un autre script de la forme :
lorsque le tablespace est en mode sauvegarde, si une modification intervient sur un objet de celui-ci,
des reprises seront créées, ce qui surchargera la phase de récupération lorsque le tablespace sera à nouveau
placé dans le mode normal : donc veillez à effectuer cette opération lorsque le serveur est le moins sollicité. Lorsqu'on positionne le mode sauvegarde, on peut alors copier le fichier de données, on peut effectuer cette copie sans au préalable avoir placé le tablespace dans ce mode, cependant la sauvegarde qu'on obtiendra sera inutilisable. Pour vérifier que le mode sauvegarde est bien activé, vérifiez le fichier des alertes (l'altération d'un tablespace y est consignée) ou consultez la vue v$backup :
Cette vue nous apprend, que le fichier 5 du tablespace TOOLS est en phase de récupération,
et qu'il a été mis dans cet état le 20/11/03.
4. RESTAURATION DES DONNEES4.1. 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 :
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.
4.2. 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. 4.2.a. 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.
4.2.b. 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 :
La base de données est bien en mode ARCHIVELOG, ainsi les redo logs seront archivés
à chaque switch assurant une sécurisation optimale de la base de données. Je vous rappelle que ces archives ne peuvent être utilisées que sur la base de données sauvegardée,
il convient donc de faire une sauvegarde complète (à froid de préférence) au plus vite suite à cette manipulation. Vous pouvez consulter l'état des paramètres relatifs à l'archivage avec la commande suivante :
4.2.c. 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 datafile
c:\oracle\oradata\BD0\users01.dbf. La perte d'un datafile provoque immédiatement l'erreur suivante et arrête la base de données :
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 :
4.2.d. 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.
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.
Lançons maintenant la récupération (RECOVER DATABASE) en indiquant le SCN 383077 trouvé précédemment :
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 :
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.
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 :
La commande RECOVER offre d'autres possibilités dont voici quelques exemples :
5. DUPLICATION D'UNE BASE DE DONNEES5.1. Introduction
Il existe différents moyens de dupliquer une base données, soit en passant par une sauvegarde logique de la base de données qu'on importe sur la base clone
(Utilitaires EXPORT /IMPORT). Une autre méthode consiste à utiliser RMAN
(Recovery Manager), et enfin dernière solution que nous étudierons durant ce chapitre qui est une copie à partir d'une sauvegarde incohérente (hot backup).
Cette méthode permet donc de créer une copie exacte de la base de données, que vous pourrez utiliser pour tester si vos sauvegardes sont correctes et si une
restauration à partir de cette sauvegarde fonctionne correctement. Avant de commencer n'oubliez pas que si vous êtes sous Windows, il existe une étape de plus
par rapport à Linux ou Unix qui consiste en la création du service de l'instance. Ici, nous copierons bd0 dans bd1, sur le même serveur Windows.
Précautions d'usage
5.2. Préparation à la création d'une base de données clone
5.3. Fichier d'initialisation
Copiez le fichier de BD0 dans BD1.
Dans %oracle_home%\dbs\bd1.ora (qui s'ouvre dans notepad) ajoutez ou modifiez le paramètre ifile :
Enfin, modifiez le fichier c:\oracle\admin\bd1\pfile\initbd1.ora pour remplacer les références à bd0 et son arborescence.
5.4. Fichier de mots de passe
Bien que cela ne soit pas une étape primordiale à la création d'une base de données, il est fortement conseillé de créer ce fichier, dans un souci de sécurisation de la base de données.
File définit le chemin et le nom du fichier de mots de passe. Password est le mot de passe pour les comptes SYS et INTERNAL. Entries est le nombre maximum de comptes ayant le privilège OPER et DBA. 5.5. Création de services sous Windows
Cette étape est nécessaire sous Windows, par la suite vous pouvez aller configurer directement, dans la base de registre ou par le biais d'ORADIM, le démarrage automatique ou pas de
l'instance lors du démarrage du serveur.
5.6. Sauvegarde de la base de donnée source
Je vous renvoie au paragraphe des sauvegardes pour cette étape : Sauvegarde qui décrit
le process à appliquer pour faire une sauvegarde complète de la base.
5.7. Préparer le script de création du fichier de contrôle
Au lieu de saisir manuellement toutes les commandes nécessaires pour la création des différents fichiers de contrôle de la base, nous allons contourner le problème grâce à la commande suivante :
Cette commande permet de générer un script de création des controlfiles, ce script permet alors de modifier les chemins des datafiles et redos de l'instance cible.
Il est généré dans le répertoire des traces utilisateurs indiqué par le paramètre user_dump_dest de la base source. Recherchez le dernier fichier trace généré (ce devrait être le résultat de la commande précédente) et copiez-le dans le répertoire c:\oracle\admin\bd1\create. Ce script contient des informations non pertinentes pour notre besoin, il convient donc de l'adapter : épurez-le en ne gardant que le code de la section resetlogs, adaptez les chemins de fichier à la nouvelle structure, ajoutez l'option PFILE au démarrage et modifiez REUSE "BD0" par SET "BD1" pour renommer la base. Vous devriez obtenir un fichier similaire au suivant :
Enfin, exécutez le script ainsi obtenu.
5.8. Récupération de la base de données
A moins d'avoir restauré une sauvegarde à froid, il est nécessaire de rejouer les redos comme vu au paragraphe 4.2.c. Commençons par indiquer le chemin des archivelogs de la base bd0 avant de lancer la récupération proprement dite :
5.9. Démarrage de la base de données
Nous arrivons à l'objectif fixé, il ne reste plus qu'à ouvrir la base de données.
6. BASE DE SECOURS : STANDBY DATABASE6.1. Introduction
Si comme nous le supposions au chapitre 3, vous êtes dans un système à haute disponibilité voir même à très haute disponibilité,
la moindre indisponibilité même courte de la base de données peut s'avérer être incompatible avec l'activité de l'entreprise (imaginez donc une indisponibilité
de Developpez.com ;-)). Si votre structure ne peut se permettre un temps d'attente trop élevé, vous devez donc trouver un moyen de disposer rapidement d'une autre base de production opérationnelle. Oracle a tout prévu, cela consiste en la création d'une base de données de secours (ou Standby Database in English). Cette solution inclut deux bases de données. La première qui est la base de données principale (dite également primaire ou source), c'est la base active. La seconde est la base de secours, il s'agit d'une copie de la base principale. La base de secours a généralement le même nom d'instance et le même nom de base de données (sauf si elle est sur le même hôte que la base principale : déconseillé puisque ne couvre pas la panne du serveur). Cette solution existe depuis la version 7.3 d'Oracle, puis avec la version 8.0, une nouvelle solution à été introduite avec l'utilitaire RMAN. Le processus de fonctionnement se déroule en 3 étapes principales :
Précautions d'usage
6.2. Création d'une base de secours
Reprenons le script du chapitre précédent pour créer l'arborescence :
Sous Linux/Unix il est possible de créer des liens vers le fichier des mots de passe et
les fichiers de configuration NET*8 (tnsnames.ora, sqlnet.ora, listener.ora). Sinon, une copie de fichier est nécessaire,
pensez alors bien à modifier ces fichiers lorsqu'ils sont modifiés pour la base principale.
6.3. Sauvegarde à chaud de la base de secours
Je vous renvoie au paragraphe des sauvegardes pour cette étape : Sauvegarde qui décrit
le process à appliquer pour faire une sauvegarde complète de la base.
6.4. Configurer le fichier de paramètre de la base de secours
Voila un exemple fichier d'initialisation spécifique pour la base de secours :
6.5. Monter la base de secours
6.6. Récupération automatique
Lorsque la récupération automatique est activée, on commence par la configuration de NET*8 pour que le processus ARCH de la base principale communique avec le processus RFS de la base de secours.
Il faut ensuite placer la base dans le mode de récupération. Cela a pour conséquence de copier et d'appliquer dynamiquement les fichiers REDO archivés. Il faut donc configurer le processus ARCH
de la base principale pour lui indiquer d'archiver les fichiers REDO vers un service NET*8 en plus du répertoire local.
6.6.a. Configuration des services NET*8
Soit grâce à l'utilitaire NET*8 soit par action directe sur les fichiers : listener.ora, sqlnet.ora et tnsnames.ora, vous devez créer un service pour la base de base de données nommé BD1. Pour le listener, utilisez le protocole IPC si votre base de secours est sur le même hôte que la base principale. Les fichiers listener.ora, sqlnet.ora et tnsnames.ora se trouvent généralement dans le répertoire suivant : %oracle_home%/network/admin. Lorsqu'on crée un nouveau service de base de données, en utilisant le protocole IPC pour le listener, ainsi qu'un nouveau nom de service TNS associé, le but est évidemment de permettre à la base principale BD0 de se connecter via le listener à la base de secours. Une connexion est donc établie chaque fois qu'un fichier REDO archivé devra être copié depuis la base principale vers celle de secours. Le listener doit être redémarré pour que ces changements soient pris en compte (via la commande Shell lsnrctl reload). Le fichier tnsnames.ora de la base de secours doit utiliser le protocole IPC car elle est locale, par contre le fichier de la base principale doit utiliser le protocole TCP, car les archivelogs sont transmis via le réseau. 6.6.b. Mode de récupération
Nous pouvons donc passer à la configuration de la base de secours. Plus précisément il faut configurer la base dans le mode "Récupération". Pour cela connectez-vous à la base en tant que SYS puis saisissez la commande suivante :
Dans ce cas là, le processus d'arrière plan RFS de la base de secours reçoit les archives transmises par la base principale, RFS met également le fichier de contrôle
à jour avec les nouvelles informations d'archivage. Le fichier est appliqué dès que ce dernier est disponible dans la destination d'archivage. Ce mécanisme de récupération
vérifie la présence de tout nouveau fichier REDO toutes les 15 secondes et ne prend fin qu'à l'émission de la commande suivante :
La configuration de la base principale à pour but essentiel de lui indiquer d'envoyer les fichiers archivelogs au nouveau service. Pour cela vous devez ajouter une seconde
destination d'archivage dans le fichier de paramètre : log_archive_dest_3="mandatory services=BD1 reopen=30"
Le mot clé mandatory signifie que les fichiers archivelogs doivent être transférés avec succès avant de pouvoir être réutilisé en ligne. Le mot clé reopen définit le délai requis en seconde avant de procéder à
une nouvelle tentative de transfert si une erreur est retournée au processus ARCH. Il existe également des commandes dynamiques permettant de désactiver ou d'activer la transmission des fichiers REDO :
6.6.c. Configuration de la base principale
Mettre fin à la phase de récupération :
Ouvrir la base de données BD1 en lecture seul :
Pour rebasculer dans le mode de récupération :
Cette phase est importante car elle permet que l'archivage fonctionne et que les changements opérés sur la base principale soient logiquement répercutés sur la base de secours. Si une base de secours est activée, elle ne pourra revenir dans son état précédent.
6.7. Activer la base de secours
Cette phase est importante car elle permet à l'archivage de fonctionner et d'appliquer les changements de la base principale sur la base de secours. Si une base de secours est activée,
elle ne pourra revenir dans son état précédent.
7. UTILISATION DU LOGMINER7.1. Introduction
Puisque nous parlons de récupération incomplète ou limitée dans le temps, le logminer peut être une bonne
solution pour déterminer ce point d'arrêt dans le temps. C'est également un moyen de lire les fichiers archivelogs et en ligne,
mais surtout de défaire ou de refaire des instructions. Le logminer se compose d'un jeu de vues du dictionnaire
et de quelques procédures stockées. Plus précisément, Oracle affecte à chaque table un numéro d'objet et à chacune de ses colonnes un identifiant qui signale le type d'objet (date, varchar, number …) grâce à l'emploi du fichier de dictionnaire Oracle traduit les identifiants des tables ou de colonnes par des noms que nous lui avons affectés. Autre précision le logminer doit être installé pour être utilisable, cependant il peut être installé sur une instance et analyser une autre instance. Vous noterez qu'un autre article spécifique à logminer est disponible : ICI 7.2. Installation du LOGMINER7.2.a. Paramètres pré-requis
Le paramétre UTL_FILE_DIR doit être positionné pour ouvrir un accès en lecture/écriture à un répertoire. Par exemple : utl_file_dir="c:\oracle\utl, c:\oracle\utl2". Tous les exemples sont exécutés sous le compte SYS. 7.2.b. Création du fichier de dictionnaire
Lancez la procédure de création http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_logma2.htm#76868.
Elle va interroger les tables du dictionnaire principal de la base courante et crée un fichier texte avec leur contenu;
ce fichier est placé dans le répertoire spécifié dans l'appel de la procédure.
La mise en place d'un fichier de dictionnaire n'est pas obligatoire mais elle améliore grandement
la lisibilité des fichiers REDO et des informations que nous irons chercher dans la vue dynamique V$LOGMNR_CONTENTS,
et facilite donc de ce fait le travail du DBA. Plus précisément le fichier du dictionnaire est utilisé par le logminer
pour convertir chaque identifiant interne d'objet en nom de structure plus explicite, par exemple ce n'est pas l'object_id mais bien l'object_name
qui sera mentionné. Quelques précautions sont à prendre lors de la création du fichier de dictionnaire. Tout d'abord veillez bien à ce que le fichier du dictionnaire soit en rapport avec la date des fichiers REDO, à savoir si votre fichier date et qu'il ne recense pas des objets nouvellement crées, logminer ne sera pas en mesure d'afficher le nom de l'objet ni de ses éventuelles colonnes. Un fichier de dictionnaire doit être créé dans la base à l'origine du journal de reprise à analyser. Nous ne pouvons pas nous servir d'un fichier de la base BD0 pour analyser BD1. 7.2.c. Spécifier les fichiers LOG à analyser
Logminer analysera les fichiers REDO que nous allons lui indiquer, par conséquent, nous devons lui indiquer les fichiers à analyser grâce à
la procédure http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_logmn3.htm#76673
L'option DBMS_LOGMNR.NEW permet de créer une nouvelle list de fichier, DBMS_LOGMNR.ADDFILE permet d'ajouter un fichier à cette liste et
DBMS_LOGMNR.REMOVEFILE permet de supprimer un fichier de la liste. La vue V$LOGMNR_LOG permet de vérifier que le fichier a bien été pris en compte.
Vous l'aurez compris, db_name, tread_sqn et filename représentent successivement, le nom de la base de données, le numéro de séquence du fichier
et son chemin sur le disque.
7.2.d. Lancer l'analyse
La procédure http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_logmn3.htm#77174
accepte différentes options, notamment un SCN de départ et/ou un SCN de fin pour délimiter le champ de l'analyse, ou une horodate de début et/ou de fin.
Le contenu des fichiers est consultable dans la vue V$LOGNMR_CONTENTS.
7.2.e. La vue V$LOGNMR_CONTENTS
Les fichiers recensés dans V$LOGMNR_LOGS sont lus en séquence et les données sont retournées dans la structure définie par V$LOGMNR_CONTENTS. Cette vue se décompose en 53 colonnes.
Voyons d'un peu plus prés quelles sont les colonnes les plus pertinentes :
Grâce à la colonne SQL_UNDO nous allons donc pouvoir annuler la modification d'une mise à jour, insertion, suppression ou toute autre opération portant sur un objet de la base de données.
Mais vous pouvez également, connaître quel utilisateur a effectué ces modifications ainsi que l'identifiant de la machine (sauf si l'opération a été effectuée par le biais d'une application tierce). Autre tâche que peut effectuer pour vous le LOGMINER c'est celle d'auditer votre base de données ou vos objets. L'avantage par rapport à l'audit de base est le fait important que le LOGMINER, contrairement à l'audit, n'ajoute pas un traitement de service susceptible de nuire aux performances. Il existe une version graphique du LOGMINER à partir de la version 9i intégrée à OEM. 8. Annulation d'un ordre DML
Oracle 9i permet de positionner une session dans le passé pour restituer les blocs de données sauvegardés dans le UNDO.
Cette méthode est une excellente alternative à Logminer pour annuler une erreur de saisie par exemple. Pour plus de détail sur le Flashback Query, vous pouvez lire ce tutoriel : Le FLASHBACK QUERY sous Oracle 9i. 9. Bibliographie
Ces documents sont tous issus de la documentation d'Oracle en ligne et nécessitent un enregistrement gratuit. Backup and Recovery Concepts Oracle Data Guard Concepts and Administration Using LogMiner to Analyze Redo Logs (Chapitre 9 de Oracle9i Database Administrator's Guide) Flashback Query (Chapitre 20 de Oracle9i Database Concepts) Net Services Administrator's Guide Remerciement
Je tiens à remercier toute l'équipe de Developpez.com pour son aide dans la relecture et l'amélioration du présent tutoriel. Un grand merci à Orafrance sans qui ce document
n'aurai jamais pu voir le jour, merci à toi pour ta patience et ton expertise, qui ont rendu ce document meilleur. Merci également à Beuss pour la correction de l'orthographe.
|
Copyright © 2005 Jaouad. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.