Fichiers de journalisation : Administration

Date de publication : le 20 Octobre 2005

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.