Developpez.com - Oracle
X

Choisissez d'abord la catégorieensuite la rubrique :


Fichiers de journalisation : Administration

Date de publication : le 20 Octobre 2005

Par Mohammed Bouayoun
 


I. Introduction
A. Contenu du Redo Log
B. Comment Oracle écrit dans les fichiers de journalisation
II. Informations sur les fichiers de journalisation
III. Création des groupes et des membres de journalisation
A. Création des groupes de journalisation
B. Création des membres de journalisation
IV. Remplacement et renommination des membres de journalisation
V. Suppression du groupe de journalisation
VI. Suppression des membres de journalisation
VII. Forcer les Log Switchs
VIII. Vérification des blocs dans les fichiers de journalisation
IX. Initialisation des fichiers de journalisation


I. Introduction

Oracle utilise les journaux redo pour être sûre que toute modification effectuée par un utilisateur ne sera pas perdue s'il y'a défaillance dans le système. Les journaux redo sont essentiels pour les processus de restauration. Quand une instance s'arrête anormalement, il se peut que certains informations dans les journaux redos ne soient pas encore écrites dans les fichiers de données. Oracle dispose les journaux redo en groupes. Chaque groupe à au moins un journal redo. Vous devez avoir au minimum deux groupes distincts de journaux redo (aussi appelé redo threads), chacun contient au minimum un seul membre.

Chaque base de données à ses groupes de journaux redo. Ces groupes, multiplexés ou non, sont appelés instance du thread de redo. Dans des configurations typiques, une seule instance de la base accède à la base Oracle, ainsi, seulement un thread est présent. Dans un environnement RAC, deux ou plusieurs instances accèdent simultanément une seule base de données et chaque instance à son propre thread de redo

Chaque base de données à ses groupes redo log. Ces groupes, multiplexés ou non, sont appelés instance thread de redo. Dans des configurations typiques, une seule instance de la base accède à la base Oracle, ainsi, seulement un thread est présent. Dans un environnement RAC, deux ou plusieurs instances accèdent simultanément une seule base de données et chaque instance à son propre thread de redo.

Groupe de fichiers de journalisations et les membres

A. Contenu du Redo Log

Les fichiers de journalisation sont remplis par des enregistrements redo. Un enregistrement redo, aussi appelé une entrée redo, est composé d'un groupe de vecteurs de change, qui est une description d'un changement effectué à un bloc de la base. Par exemple, si on modifie la valeur d'un salaire dans la table employee, on génère un enregistrement redo qui contient des vecteurs de change décrivant les modifications sur le bloc du segment de données de la table, le bloc de données du segment undo et la table de transaction des segments undo.


Les entrées redo enregistre les données qu'on peut utiliser pour reconstruire touts les changements effectués sur la base, inclus les segments undo. De plus, le journal redo protége aussi les données rollback. Quand on restaure la base en utilisant les données redo, la base lit les vecteurs de change dans les enregistrements redo et applique le changement aux blocs appropriés.

Les enregistrements redo sont mis d'une façon circulaire dans le buffer redo log de la mémoire SGA. Et ils sont écrits dans un seul fichier de journalisation par le processus LGWR. Dés qu'une transaction est comité, LGWR écrit les enregistrements redo de la transaction depuis le buffer redo log du SGA vers le fichier journal redo, et attribut un SCN pour identifier les enregistrements redo pour chaque transaction comité. Seulement quand tous les enregistrements redo associés à la transaction donnée sont sans incident sur le disque dans les journaux en ligne et que le processus utilisateur a notifié que la transaction à été comité.


Les enregistrements redo peuvent aussi être écrits dans le fichier journal redo avant que la transaction correspondante soit comité. Si le buffer redo log est plein ou une autre transaction à comité, LGWR vide toutes les entrées des journaux redo du buffer redo log dans le fichier journal redo, bien que certain enregistrements redo ne devrait pas être comités. Si nécessaire, oracle peut roll back ces changements.


B. Comment Oracle écrit dans les fichiers de journalisation

La base oracle exige au minimum deux fichiers de journalisation.

LGWR écrit dans les fichiers de journalisation d'une façon circulaire. Quand le fichier journal redo courant est plein, LGWR commence à écrire dans le prochain fichier journal redo disponible. Quand le dernier est plein, LGWR commence à écrire dans le premier journal redo.

Figure 1
  • Si l'archivage est désactivé (la base en mode NOARCHIVELOG), un fichier de journalisation plein est disponible après que les changements enregistrés dedans seront écrits dans les fichiers de données.
  • Si l'archivage est activé (La base est en mode ARCHIVELOG), un fichier de journalisation plein est disponible pour le processus LGWR après que les changements effectués dedans seront écrits dans les fichiers de données et était archivé.
Les fichiers journaux Active (Current) et Inactive

Oracle utilise un seul fichier de journalisation à la fois pour stocker les enregistrements redo depuis le redo log buffer. Le fichier de journalisation dont le processus LGWR est entrains d'écrire dedans est appelé le fichier de journalisation courant.

Les fichiers de journalisation qui sont nécessaire à la restauration de la base sont appelés les fichiers de journalisation actives. Les fichiers de journalisation qui ne sont pas nécessaire à la restauration s'appelles les fichiers de journalisation inactives.

Si on a activé l'archivage (mode ARCHIVELOG), alors la base ne peut pas réutiliser ou sur écrire dans le fichier de journalisation en ligne tant que l'un des processus ARCn n'a pas archivé ses contenus. Si l'archivage est désactivé (mode NOARCHIVELOG), alors quand le dernier fichier de journalisation est plein, LGWR continue en sur écrivant le premier fichier active disponible.

Les Log Switches et les numéros de séquence du journal

Un log switch est le point où la base arrête d'écrire dans l'un des fichiers de journalisation en ligne et commence à écrire dans un autre. Normalement, un log switch survient quand le fichier de journalisation courant est complètement rempli et il doit continuer à écrire dans le fichier de journalisation suivant. Pourtant, on peut configurer les log switche de se reproduire dans des intervalles réguliers, sans soucier si le fichier de journalisation en cours est complètement rempli. On peut aussi forcer les log switch manuellement.

Oracle assigne à chaque fichier de journalisation un nouveau numéro de séquence chaque fois un log switch arrive et le processus LGWR commence à écrire dedans. Quand oracle archive les fichiers de journalisation, le log archivé garde le numéro de séquence du journal. Le fichier de journalisation qui est recyclé fournis le prochain numéro de séquence du journal disponible.

Chaque fichier de journalisation en ligne ou archivé est identifié uniquement par son numéro de séquence (log sequence).

Durant un crash, l'instance ou une restauration media , la base applique proprement les fichiers de journalisation dans un ordre croissant en utilisant le numéro de séquence du fichier de journalisation archivé nécessaire et des fichiers de journalisation.


II. Informations sur les fichiers de journalisation

Les vues V$THREAD, V$LOG, V$LOGFILE et V$LOG_HISTORY fournis des informations sur les journaux Redo.

La vue V$THREAD donne les informations sur le fichier de journalisation en cours.

SQL> desc v$thread Nom NULL ? Type ----------------------------------------- -------- ------------ THREAD# NUMBER STATUS VARCHAR2(6) ENABLED VARCHAR2(8) GROUPS NUMBER INSTANCE VARCHAR2(80) OPEN_TIME DATE CURRENT_GROUP# NUMBER SEQUENCE# NUMBER CHECKPOINT_CHANGE# NUMBER CHECKPOINT_TIME DATE ENABLE_CHANGE# NUMBER ENABLE_TIME DATE DISABLE_CHANGE# NUMBER DISABLE_TIME DATE LAST_REDO_SEQUENCE# NUMBER LAST_REDO_BLOCK NUMBER LAST_REDO_CHANGE# NUMBER LAST_REDO_TIME DATE SQL> select * from v$thread; TRD# STAT ENABLED GRPS INST OPEN CURRENT SEQ CHECKP CHECKP ENABLE ENABLE DISABLE DIS LAST LAST LAST LAST REDO REDO REDO REDO TIME GROUP# CHANGE TIME CHANGE# TIME CHANGE# TIME SEQ BLOCK CHANGE# TIME ---- ---- ------ ---- ---- ---- ------- --- ------- -------- ------- ------ ------- ---- ---- ------ ------- --------- 1 OPEN PUBLIC 3 b10g2 19/10/05 2 81 3201917 19/10/05 547780 01/09/05 0 81 3755 3203391 19/10/05
La vue V$LOG donne les informations en lisant dans le fichier de contrôle au lieu dans le dictionnaire de données.

SQL> desc v$log Nom NULL ? Type ----------------------------------------- -------- ------------- GROUP# NUMBER THREAD# NUMBER SEQUENCE# NUMBER BYTES NUMBER MEMBERS NUMBER ARCHIVED VARCHAR2(3) STATUS VARCHAR2(16) FIRST_CHANGE# NUMBER FIRST_TIME DATE SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME ------ ------- --------- ----- ------- --- ------ ------------- -------- 1 1 41 52428800 1 NO INACTIVE 1867281 18/09/05 2 1 42 52428800 1 NO CURRENT 1889988 18/09/05 3 1 40 52428800 1 NO INACTIVE 1845207 18/09/05
Pour voir les noms des membres d'un groupe on utilise la vue V$LOGFILE

SQL> desc v$logfile Nom NULL ? Type ----------------------------------------- -------- --------------- GROUP# NUMBER STATUS VARCHAR2(7) TYPE VARCHAR2(7) MEMBER VARCHAR2(513) IS_RECOVERY_DEST_FILE VARCHAR2(3) SQL> select * from v$logfile; GROUP# STATUS TYPE MEMBER IS_RECOVERY_DEST_FILE ------ ------- ------- ------------------- --------------------- 3 STALE ONLINE D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO03.LOG NO 2 ONLINE D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO02.LOG NO 1 STALE ONLINE D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO01.LOG NO
GROUP# est le numéro du groupe Redo Log.

STATUS prends la valeur INVALID si le fichier est inaccessible, STALE si le fichier est incomplet , DELETED si le fichier n'est plus utilisé et la valeur blanc si le fichier est en cours d'utilisation.

MEMBER est le nom du membre Redo Log

A partir de la 10g on'a une nouvelle colonne dans la vue V$LOGFILE : IS_RECOVERY_DEST_FILE. Cette colonne se trouve dans les vues V$CONROLFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY, V$DATAFILE et V$BACKUP_PIECE, elle prends la valeur YES si le fichier à été crée dans la région de restauration flash.

SQL> select * from V$LOG_HISTORY; RECID STAMP THREAD# SEQUENCE# FIRST_CHANGE# FIRST_TI NEXT_CHANGE# RESETLOGS_CHANGE# RESETLOG ---------- ---------- ---------- ---------- ------------- -------- ------------ ----------------- -------- 1 567895614 1 1 547780 01/09/05 578189 547780 01/09/05 2 567900275 1 2 578189 01/09/05 596011 547780 01/09/05 3 567981823 1 3 596011 01/09/05 650604 547780 01/09/05 4 568027925 1 4 650604 02/09/05 684588 547780 01/09/05 5 568203418 1 5 684588 03/09/05 714521 547780 01/09/05 6 568233638 1 6 714521 05/09/05 752984 547780 01/09/05 7 568244091 1 7 752984 05/09/05 781475 547780 01/09/05 8 568245159 1 8 781475 05/09/05 803278 547780 01/09/05 9 568302950 1 9 803278 05/09/05 851785 547780 01/09/05 10 568324398 1 10 851785 06/09/05 886760 547780 01/09/05 11 568377277 1 11 886760 06/09/05 915694 547780 01/09/05 12 568379659 1 12 915694 07/09/05 939132 547780 01/09/05 13 568380827 1 13 939132 07/09/05 960371 547780 01/09/05 14 568413353 1 14 960371 07/09/05 995152 547780 01/09/05 15 568469116 1 15 995152 07/09/05 1041080 547780 01/09/05 16 568496994 1 16 1041080 08/09/05 1080879 547780 01/09/05 17 568549511 1 17 1080879 08/09/05 1120814 547780 01/09/05 18 568570660 1 18 1120814 09/09/05 1157622 547780 01/09/05 19 568642280 1 19 1157622 09/09/05 1201919 547780 01/09/05 20 568689580 1 20 1201919 10/09/05 1229879 547780 01/09/05 21 568726874 1 21 1229879 11/09/05 1256968 547780 01/09/05 22 568768789 1 22 1256968 11/09/05 1318924 547780 01/09/05 23 568808467 1 23 1318924 11/09/05 1347512 547780 01/09/05 24 568840794 1 24 1347512 12/09/05 1387014 547780 01/09/05 25 568884753 1 25 1387014 12/09/05 1421180 547780 01/09/05 26 568937926 1 26 1421180 13/09/05 1464514 547780 01/09/05 27 568980429 1 27 1464514 13/09/05 1516026 547780 01/09/05 28 569011439 1 28 1516026 14/09/05 1554026 547780 01/09/05 29 569093571 1 29 1554026 14/09/05 1587596 547780 01/09/05 30 569095068 1 30 1587596 15/09/05 1608898 547780 01/09/05 31 569096742 1 31 1608898 15/09/05 1630275 547780 01/09/05 32 569109860 1 32 1630275 15/09/05 1651975 547780 01/09/05 33 569152161 1 33 1651975 15/09/05 1680839 547780 01/09/05 34 569182698 1 34 1680839 16/09/05 1717452 547780 01/09/05 35 569204154 1 35 1717452 16/09/05 1743613 547780 01/09/05 36 569243480 1 36 1743613 17/09/05 1767029 547780 01/09/05 37 569278536 1 37 1767029 17/09/05 1793935 547780 01/09/05 38 569353006 1 38 1793935 17/09/05 1824055 547780 01/09/05 39 569353855 1 39 1824055 18/09/05 1845207 547780 01/09/05 40 569356243 1 40 1845207 18/09/05 1867281 547780 01/09/05 41 569368110 1 41 1867281 18/09/05 1889988 547780 01/09/05 41 ligne(s) sÚlectionnÚe(s).
La vue V$LOG_HISTORY contient des informations concernant l'historique des fichiers journaux à partir du fichier de contrôle. Le maximun que peut retenir la vue depends du paramètre MAXLOGHISTORY.

La seule solution pour initialiser cette vue, il faut recréer le fichier de contrôle. voir mon tuto : fichier de contôle ou utiliser CONTROL_FILE_RECORD_KEEP_TIME.


III. Création des groupes et des membres de journalisation

Pour créer un nouveau groupe de fichier de journalisation ou un membre, on doit avoir le privilège système ALTER DATABASE. La base peut avoir au maximum MAXLOGFILES groupes.


A. Création des groupes de journalisation

Pour créer un nouveau groupe de fichiers journalisation, on utilise la requête ALTER DATABASE avec la clause ADD LOGFILE.

Par exemple ::

ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 500K;
Il faut spécifier le chemin et le nom complet pour les nouveaux membres, sinon ils seront crées dans le répertoire par défaut ou dans le répertoire courant suivant l'OS.
On peut spécifier le numéro qui identifie le groupe en utilisant la clause GROUP :

ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 500K;
L'utilisation des numéros de groupes facilite l'administration des groupes de journalisation. Le numéro de groupe doit être entre 1 et MAXLOGFILES. Surtout ne sauter pas les numéros de groupes (par exemple 10, 20,30), sinon on consomme inutilement de l'espace dans les fichiers de contrôles.


B. Création des membres de journalisation

Dans certain cas, il n'est pas nécessaire de créer complètement un groupe de fichiers de journalisation. Le groupe peut déjà exister car un ou plusieurs membre a été supprimé (par exemple, suite une panne d'un disque). Dans ce cas, on peut ajouter de nouveaux membres dans le groupe existant.

La base peut avoir au maximum MAXLOGMEMBERS membres.

Pour créer un nouveau membre de fichier de journalisation d'un groupe existant, on utilise la commande ALTER DATABASE avec la clause ADD LOGFILE MEMBER. Dans l'exemple suivant on ajoute un nouveau membre au groupe de journalisation numéro 2 :

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;
Noter que le nom du fichier doit être indiqué, mais sa taille n'est pas obligatoire. La taille du nouveau membre est déterminé à partir de la taille des membres existants du groupe.

Quand on utilse ALTER DATABASE, on peut identifier alternativement le groupe cible en spécifiant tous les autres membres du groupe dans la clause TO, comme le montre l'exemple suivant :

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');
Il faut spécifier en entier, le nom du nouveau membre en indiquant son chemin dans l'OS. Sinon, le fichier sera crée dans le répertoire par défaut ou dans le repertoire courant suivant l'OS. Il faut noter aussi que la statu du nouveau membre est INVALID. C'est normale, il prendra la valeur vide dès sa première utilisation.

IV. Remplacement et renommination des membres de journalisation

On peut utiliser les commandes OS pour déplacer les fichiers de journalisation, après on utilise la commande ALTER DATABSE pour donner leurs nouveaux noms (emplacement) connu par la base. Cette procèdure est necessaire, par exemple, si le disque actuellement utilisé pour certains fichiers redo logs doit être retiré, ou si les fichiers de données et certains fichiers de journalisation se trouvent dans un même disque et devrait être séparés pour réduir la contention.

Pour renommer un membre de fichiers de journalisation, on doit avoir le privillège système ALTER DATABASE.

En plus, On doit aussi avoir les privilèges système pour copier les fichiers dans le repertoire désiré et les privilèges pour ouvrir et sauvegarder la base de données.

Avant de déplacer les fichiers de journalisations, ou tous autres changements de structures de la base, sauvegarder complètement la base. Par precaution, après la renommination ou le déplacement d'un ensemble de fichiers fichiers de journalisation, effectuer immediatement une sauvegarde du fichier de contrôle.

Pour déplacer les fichiers de journalisations, on utilise les étapes suivantes :

  • Les fichiers journaux sont situé dans deux disques : diska et diskb.
  • Les fichiers de journalisation sont duplixés : un groupe est constitué des membres /diska/logs/log1a.rdo et /diskb/logs/log1b.rdo, et le second groupe est constitué des membres /diska/logs/log2a.rdo et /diskb/logs/log2b.rdo.
  • les fichiers de journalisation situés dans le disque diska doit être deplacer dans le diskc. le nouveau nom du fichier refléte le nouveau emplacement : /diskc/logs/log1c.rdo et /diskc/logs/log2c.rdo.
Les étapes à suivre pour renommer les membres des journaux

1. Arrêter la base.

SHUTDOWN
2. Copier les fichiers de journalisation dans le nouveau emplacement.

On peut utiliser la commande HOST pour lancer des commandes OS sans sortir de SQL*Plus. Sous certains OS en utilise un carctère à la place de HOST. Par exemple, sous UNIX on utilise le point d'exclamation (!).
L'exemple suivant utilise les commandes OS (UNIX) pour déplacer les membres des journaux dans un nouveau emplacement :

mv /diska/logs/log1a.rdo /diskc/logs/log1c.rdo mv /diska/logs/log2a.rdo /diskc/logs/log2c.rdo
3. Démarrer la base avec un mount, sans l'ouvrir.

CONNECT / as SYSDBA STARTUP MOUNT
4. Renommer le membre de fichier de journalisation.

Use the ALTER DATABASE statement with the RENAME FILE clause to rename the database redo log files.

ALTER DATABASE RENAME FILE '/diska/logs/log1a.rdo', '/diska/logs/log2a.rdo' TO '/diskc/logs/log1c.rdo', '/diskc/logs/log2c.rdo';
5. Ouvrir la base normalement.

La modification du fichier journal prends effet à l'ouverture de la base.

ALTER DATABASE OPEN;

V. Suppression du groupe de journalisation

Dans certains cas, on doit supprimer un groupe en entier. Par exemple, on veut réduir le nombre de groupes. Dans d'autres cas, on doit supprimer un ou plusieurs membres. Par exemple, si certains memebres se trouvent dans un disque défaillant.

Suppression d'un groupe

Pour supprimer un groupe de journaux, on doit avoir le privilège système ALTER DATABASE.

Avant de supprimer un groupe de journaux, il faut prendre en considération les restrictions et les precautions suivantes :

  • Une instance réclame au minimum deux groupes de fichiers de journalisations, sans soucier du nombre de membres dans le groupe. (Un groupe contient un ou plusieurs membres.)
  • On peut supprimer un groupe de journaux, seulement s'il est inactif. Si on a besoin de supprimer le groupe courant, en premier, on force un switch log.
  • S'assurer que le groupe de journaux est bien archivé (si l'archivage est activé) avant de le supprimer.
Pour voir ce qui se passe, utilisez la vue V$LOG.

SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG; GROUP# ARC STATUS ---------- --- ---------------- 1 YES ACTIVE 2 NO CURRENT 3 YES INACTIVE 4 YES INACTIVE
Supprimer un groupe de journaux avec la commande ALTER DATABASE en utilisant la clause DROP LOGFILE.

Dans cette exemple on supprime le groupe de journaux ayant comme numéro 3 :

ALTER DATABASE DROP LOGFILE GROUP 3;
Quand un groupe de journaux est supprimé de la base, et on n'utilise pas l'OMF, les fichiers OS ne seront pas supprimés du disque. Il faut utiliser les commandes OS pour les supprimés physiquement.

Quand on utilise OMF, le nettoyage des fichiers OS se fait automatiquement.


VI. Suppression des membres de journalisation

Pour supprimer un membre d'un fichier de journalisation, on doit avoir le privilège système ALTER DATABASE.

Pour supprimer un membre inactive d'un fichier de journalisation, on utilise la commande ALTER DATABASE avec la clause DROP LOGFILE MEMBER.

Suppression d'un membre

La commande suivante supprime le journal /oracle/dbs/log3c.rdo :

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';
Quand un membre d'un journal est supprimé, le fichier OS n'est pas supprimé du disque.

Pour supprime un membre d'un groupe actif, on doit forcer en premier le log switch.


VII. Forcer les Log Switchs

Le log switch se produit quand LGWR s'arrête d'écrire dans un groupe de journaux et commence à écrire dans un autre. Par defaut, un log switch se produit automatiquement quand le groupe du fichier de journalisation en cours est remplis.

On peut forcer un log switch pour que le groupe courant soit inactif et disponible pour des opérations de maintenances sur les fichiers journaux. Par exemple, on veut supprimer le groupe actuellement actif, mais on est incapable de le supprimer tant qu'il est actif. On doit aussi obliger un switch log si le groupe actuellement actif à besoin d'être archivé dans un temps spécifique avant que les membres du groupe seront complètement remplis. Cette option est utile dans des configurations où les fichiers de journalisation sont assez larges et ils prennent plus de temps pour se remplir.

Pour forcer un log switch, on doit avoir le privilège ALTER SYSTEM. Utilisez la commande ALTER SYSTEM avec la clause SWITCH LOGFILE.

La commande suivante force un log switch:

ALTER SYSTEM SWITCH LOGFILE;
Avant le log switch Après le log switch
   

VIII. Vérification des blocs dans les fichiers de journalisation

On peut configurer la base pour utiliser le CHECKSUMS, afin que les blocs des fichiers journaux soit vérifiés. Si on affecte le paramètre d'initialisation DB_BLOCK_CHECKSUM à TRUE, Oracle calcule le checksum pour chaque bloc oracle quand il écrit dans le disque, y compris les blocs des journaux. Le checksum est stocké dans l'entête du bloc.

Oracle utilise le checksum pour detecter les blocs corrompu dans les fichiers de journalisation. La base vérifie le bloc du journal quand le bloc est lit à partir du journal archivé durant la restauration et quand il écrit le bloc dans le journal archivé. Une erreur sera detecté et écrite dans le fichier d'alert, si une corruption est detectée.

Si une corruption est detecté dans un bloc du journal pendant son archivage, le système tente de lire le bloc depuis un autre membre dans le groupe. Si le bloc est corrompu dans tous les membres du groupe des journaux, alors l'archivage ne peut pas se poursuivre.

La valeur par défaut du paramètre DB_BLOCK_CHECKSUM est TRUE. La valeur de ce paramètre peut être modifié dynamiquement en utilisant ALTER SYSTEM

L'activation de DB_BLOCK_CHECKSUM diminue la performance de la base. Il faut bien surveiller les performances de la base pour décider si c'est avantageux d'utiliser le checksum de bloc de données.

IX. Initialisation des fichiers de journalisation

On peut initialiser un fichier de journalisation sans arrêter la base, par exemple, si le fichier de journalisation est corrompu.

Initialisation d'un groupe
ALTER DATABASE CLEAR LOGFILE GROUP (numero du groupe);
On peut utiliser cette commande si on ne peut pas supprimer les journaux , il y'a deux situations :

  • S'il y'a seulement deux groupes de journaux
  • Le journal corrompu appartient au groupe en cours
Si le fichier journal corrompu n'est pas encore archivé, on utilise la clé UNARCHIVED.

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP (numero du groupe);
Cette commande initialise les fichiers journaux corrompus et évite leur archivage.

Si on initialise le fichier journal qui est nécessaire pour la restauration ou la sauvegarde, on ne peut plus restaurer depuis cette sauvegarde.

Si on initialise un fichier journal non archivé, on devrait faire une autre sauvegarde de la base.
Pour initialiser un journal non archivé qui est nécessaire pour mettre un tablespace hors ligne en ligne, on utilise la clause UNRECOVERABLE DATAFILE dans la commande DATABASE CLEAR LOGFILE.

Si on initialise un journal nécessaire pour mettre un tablespace hors ligne en ligne, on sera incapable de mettre le tablespace en ligne une autre fois. On est obligé de supprimer le tablespace ou effectuer une restauration incomplète. Il faut noter que le tablespace mis hors ligne normalement n'a pas besoin de restauration.



Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Contacter le responsable de la rubrique Oracle