Les Fichiers redo

Date de publication : le 20 Octobre 2005

I. Les Fichiers Redo
I.1. Introduction
I.1.1. Contenu du Redo Log
I.1.2. Comment Oracle écrit dans les fichiers de journalisation
I.2. Informations sur les fichiers de journalisation
I.3. Création des groupes et des membres de journalisation
I.3.1. Création des groupes de journalisation
I.3.2. Création des membres de journalisation
I.4. Remplacement et renommination des membres de journalisation
I.5. Suppression du groupe de journalisation
I.6. Suppression des membres de journalisation
I.7. Forcer les Log Switchs
I.8. Vérification des blocs dans les fichiers de journalisation
I.9. Initialisation des fichiers de journalisation
II. Les Fichiers Redo Archivés
II.1. Introduction
II.2. Le mode NOARCHIVELOG et ARCHIVELOG
II.2.1. Le mode NOARCHIVELOG
II.2.2. Le mode ACHIVELOG
II.3. Changement du mode d'archivage
II.4. L'archivage manuel et l'archivage automatique
II.5. Déstination des Archives
II.5.1. Methode 1 : Utilisation du paramètre LOG_ARCHIVE_DEST_n
II.5.2. Methode 2 : LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST
II.6. Statu des destinations d'archives
II.7. Mode de transmission d'un journal
II.7.1. Mode de transmission normal
II.7.2. Mode transmission standby
II.8. Gestion des pannes des destinations archives
II.9. Trace du processus d'archivage
II.10. Informations sur les vues des fichiers redo archivés
II.10.1. Les vues dynamique
II.10.2. La commande ARCHIVE LOG LIST
III. Le Redo Log Buffer
IV. Checkpoint
IV-A. Les paramètres de checkpoint
IV-A-1. Avant la 10g
IV-A-2. Le paramètre FAST_START_MTTR_TARGET
V-B. En cours
V. Reglages des fichiers redo et du redo log buffer
V-A. log file switch completion
V-B. log file switch (checkpoint incomplete)
V-C. L'attente de l'évènement log file sync
V-A-1. fréquence très élevée des validations
V-A-2. E/S lent
V-A-3. Log Buffer trop grand
V-D. log file parallel write
VI. Le LOGMINNER
VI-A. Introduction
VI-B. Configuration du Logminer
VI-C. Utilisation du Logminer
VI-D. La vue V$LOGMNR_CONTENTS
VI-E. DBMS_LOGMNR.START_LOGMNR
VIII. Dump des fichiers Redo
A. Dump basé sur le DBA (Data Block Address)
B. Dump basé sur le RBA (Redo Block Address)
C. Dump basé sur le temps
D. Dump basé sur la couche et l'opcode.
E. Dump des informations de l'entête du fichier
F. Dump du fichier redo en entier
IX. Les fichiers redo et les sauvegardes
X. Appendice
IX.1. RBA
IX.2. RDBA et DBA

I. Les Fichiers Redo

I.1. 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 du 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

Groupe de fichiers de journalisations et les membres

I.1.1. 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 validés. Si nécessaire, oracle peut annuler ces changements.

I.1.2. 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.

I.2. 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

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.

Dans cette exemple on a l'erreur oracle suivante :

kccrsz: denied expansion of controlfile section 9 by 65535 record(s) 
the number of records is already at maximum value (65535) 
krcpwnc: following controlfile record written over: 
RECID #520891 Recno 53663 Record timestamp

On voit que le problème vient de la section 9 ce qui veut dire LOG HISTORY

SQL> select * from v$controlfile_record_section where type='LOG HISTORY' ;

TYPE 		RECORDS_TOTAL 	RECORDS_USED 	FIRST_INDEX 	LAST_INDEX 	LAST_RECID 
------------- 	------------- 	------------ 		----------- 		---------- 		---------- 
LOG HISTORY 	65535 		65535 		33864 		33863 		520892

Ce qui montre que RECORD_USED à atteint le maximum autorisé RECORD_TOTAL.

La solution est de mettre le paramètre CONTROL_FILE_RECORD_KEEP_TIME à 0 dans le fichier d'initialisation ou utiliser la commande suivante :

SQL> alter system set control_file_record_keep_time=0;

MAXLOGHISTORY augmente dynamiquement quand CONTROL_FILE_RECORD_KEEP_TIME Est different de 0 mais il ne depasse jamais la valeur 65535.

Supposons que control_file_record_keep_time = 30 (30 jours) et qu'à chaque 30 secondes un archive log est géneré.

Pour 30 jours, on'aura 86400 journaux ce qui dépassera la valeur 65535. Pour corriger le problème on met la paramètre control_file_record_keep_time à 0 et pour l'éviter on augmente la taille des fichiers redo.

I.3. 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.

I.3.1. 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.

I.3.2. 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.

I.4. 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;

I.5. 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.

I.6. 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.

I.7. 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

I.8. 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.

I.9. 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.

II. Les Fichiers Redo Archivés

II.1. Introduction

En cours

II.2. Le mode NOARCHIVELOG et ARCHIVELOG

II.2.1. Le mode NOARCHIVELOG

Quand la base est en mode NOARCHIVELOG, l'archivage des journaux est désactivé. Le fichier de contrôle indique que les groupes remplis ne sont plus nécessaires et dès qu'ils sont inactifs après un log switch, le groupe sera disponible pour une réutilisation par LGWR.

Le mode NOARCHIVELOG protège la base contre une défaillance de l'instance, mais non pas contre une défaillance media. Seulement les modifications récentes dans la base, stockés dans les groupes de fichiers redo en ligne qui seront disponible pour la restauration de l'instance.

En mode NOARCHIVELOG on ne peut pas exécuter une sauvegarde en ligne d'une tablespace. Pour restaurer la base en mode NOARCHIVELOG, on peut seulement utiliser une sauvegarde complète quand la base était fermée. Dans ce mode, il faut faire des sauvegardes régulièrement.

	LGWR écrit dans le premier fichier redo
	Lé premier fichier redo est plein. LGWR écrit dans le second fichier redo2
	Lé second fichier redo est plein. LGWR écrit dans le troisième fichier redo3
	Après que le dernier fichier redo est plein, LGWR écrit sur le premier fichier redo

II.2.2. Le mode ACHIVELOG

Quand la base est en mode ARCHIVELOG, on active l'archivage des fichiers de journalisation. Le fichier de contrôle de la base signale que les groupe contenant des fichiers de journalisation plein, ne peut pas être utiliser par LGWR tant que le groupe n'a pas été archivé.

	LGWR écrit dans le premier fichier redo
	Lé premier fichier redo est plein. LGWR écrit dans le second fichier redo2 e ARCn crée une copie de redo1
	Lé second fichier redo est plein. LGWR écrit dans le troisième fichier redo3, ARCn crée une copie du fichier redo2 et le cycle continue

II.3. Changement du mode d'archivage

Pour modifier le mode d'archivage de la base, on utilise la commande ALTER DATABASE avec la clause ARCHIVELOG ou NOARCHIVELOG et il faut être connecté avec des privilèges d'administrateur (AS SYSDBA).

Dans cette exemple on montre comment activer le mode ARCHIVELOG :

1. Arrêter la base.

SHUTDOWN

On ne peut pas modifier le mode ARCHIVELOG en NOARCHIVELOG si la base à besoin d'une restauration media.

2. Sauvegarder la base.

Avant de faire des modifications majeur dans la base, toujours sauvegarder votre base pour se protegé d'un autre nouveau problème.

3. Editer le fichier d'initialisation pour ajouter les paramètres qui spécifies la déstination des archives. (Voir Destination des archives).

4. Démarrer la base en mode mount sans l'ouvrir.

STARTUP MOUNT

5. Modifier le mode d'archivage et ouvrir la base.

ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

6. Arrêter la base..

SHUTDOWN IMMEDIATE

7. Sauvegarde la base.

La fait de modifier le mode d'archivage mettra à jours le fichier de contrôle ce qui rendra les anciens sauvegardes inutilisables.

II.4. L'archivage manuel et l'archivage automatique

Dans Oracle 10g, l'archivage automatique est activé par la commande SQL suivante :

ALTER DATABASE ARCHIVELOG;

Si la base est en mode ARCHIVELOG, Oracle archive les fichiers journaux dès qu'ils sont remplis. Le journal en entier doit être archivé avant d'être utilisé.

Avant 10g, les fichiers journaux sont marqués comme prêt pour être archivé ce qui ne signifie pas qu'ils devraient être archivés automatiquement. Il fallait renseigné le parametre d'intialisation :

LOG_ARCHIVE_START = TRUE

Mettre ce paramètre à TRUE démarera un process qui consiste à copier un fichier de journalisation dans le repertoire des journaux archivés. La destination et le format du nom des fichiers de journalisation archivés sont specifiés par deux paramètres, , LOG_ARCHIVE_DEST et LOG_ARCHIVE_FORMAT.

LOG_ARCHIVE_DEST = C:\ORANT\DATABASE\ARCHIVE

Specifie le nom du repertoire où Oracle doit écrire les fichiers archivés

LOG_ARCHIVE_FORMAT = "ORCL%S.ARC"

Specifie le format du nom des fichiers archivés. Dans ce cas, le fichier doit commencer par ORCL puis le numéro de sequence du journal et finira par .ARC.

Les autres options sont :

%s : le numéro de sequence du journal sans zero-padding à gauche

%T : le numéro du redo thread avec zero-padding

%t : le numéro du redo thread sans zero-padding

Par exemple, pour si on veut que les noms des fichiers archivés contient les numéros du thread et de la sequenec avec zero-padding :

LOG_ARCHIVE_FORMAT = "ORCL%T%S.ARC"

II.5. Déstination des Archives

On a le choix d'archiver les journaux dans une seule destination ou dans plusieurs. Si on choisit une seule destination, alors on utilise le paramètre LOG_ARCHIVE_DEST. Et si on choisit plusieurs destinations, on 'aura le choix entre 10 destinations (paramètre LOG_ARCHIVE_DEST_n) ou archiver seulement dans les destinations primaire et secondaire en utilisant LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST.

Voici un tableau qui récapitule le choix du multiplexage :

Méthode	Paramètre d'initialisation	Host	Exemple
1	LOG_ARCHIVE_DEST_n avec n entre 1 et 10	remote et local	LOG_ARCHIVE_DEST_1 ='LOCATION=/disk1/arc' LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1'
2	LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST	seulement local	LOG_ARCHIVE_DEST = '/disk1/arc' LOG_ARCHIVE_DUPLEX_DEST = '/disk2/arc'

II.5.1. Methode 1 : Utilisation du paramètre LOG_ARCHIVE_DEST_n

On utilise le paramètre LOG_ARCHIVE_DEST_n (avec n un entier antre 1 et 10) pour désigner l'un des dix destinations d'archives.

Si on utilise la clé LOCATION, il faut spécifier un répertoire valide de l'OS. Si on spécifie SERVICE, Oracle traduit le nom du service réseau à travers le fichier tnsnames.ora en descripteur de connexion. Le descripteur contient les informations nécessaires pour se connecter la base remote. Le nom du service doit être associé au SID de la base, de cette façon la base met à jours correctement la section log history du fichier de contrôle pour une base standby.

Pour fixer la destination des fichiers redo archivés en utilisant le paramètre d'initialisation LOG_ARCHIVE_DEST_n :

1. Arrêter la base.

SHUTDOWN

2. On fixe le paramètre d'initialisation LOG_ARCHIVE_DEST_n. Par exemple

LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/archive'
LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive'
LOG_ARCHIVE_DEST_3 = 'LOCATION = /disk3/archive'

Si on archive dans une base standby, on utilisera le mot clé SERVICE. Par exemple :

LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'

3. En option, on fixe le paramètre d'initialisation LOG_ARCHIVE_FORMAT.

Si le paramètre d'initialisation COMPATIBLE est fixé à 10.1.0 ou plus, la base réclame ID du resetlogs (%r) quand le paramètre LOG_ARCHIVE_FORMAT est utilisé. Par défaut sous UNIX ce paramètre est :

LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf

L'incarnation de la base change quand elle est ouverte avec l'option RESETLOGS. Le fait de spécifier %r, provoquera la capture de l'ID resetlogs dans le nom du fichier redo archivé, ce qui nous facilites d'effectuer une restauration depuis la sauvegarde de la dernière incarnation de la base.

II.5.2. Methode 2 : LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST

Si on veut spécifier au maximum deux locations, alors c'est mieux d'utiliser le paramètre LOG_ARCHIVE_DEST pour spécifier la destination d'archive primaire et LOG_ARCHIVE_DUPLEX_DEST pour spécifier la destination d'archive secondaire. Toutes les locations doivent être en local.

Pour cela, Il faut :

1. Arrêter la base.

SHUTDOWN

2. Spécifier les paramètres LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST (on peut utiliser la commande ALTER SYSTEM pour les modifiés dynamiquement).

Par exemple

LOG_ARCHIVE_DEST = '/disk1/archive'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'

3. Fixer le paramète d'initialisation LOG_ARCHIVE_FORMAT

II.6. Statu des destinations d'archives

Toutes les destinations d'archives ont des caractéristiques variables pour déterminer leur statut :

Valid/Invalid : indique si la location du disque et l'information sur le nom du service est specifié et valide.

Enabled/Disabled : indique l'état de la disponibilité de la location et si la base peut utiliser cette déstination.

Active/Inactive : Indique s'il y'a un problème pour accéder à la destination.

Plusieurs combinaisons sont possibles. Pour obtenir la statu en cours et d'autres informations sur chacune des destinations, on utilise alors la vue V$ARCHIVE_DEST.

SQL> desc V$ARCHIVE_DEST
 Name                                      Null?    Type
 ----------------------------------------- -------- -----------------------
 DEST_ID                                            NUMBER
 DEST_NAME                                          VARCHAR2(256)
 STATUS                                             VARCHAR2(9)
 BINDING                                            VARCHAR2(9)
 NAME_SPACE                                         VARCHAR2(7)
 TARGET                                             VARCHAR2(7)
 ARCHIVER                                           VARCHAR2(10)
 SCHEDULE                                           VARCHAR2(8)
 DESTINATION                                        VARCHAR2(256)
 LOG_SEQUENCE                                       NUMBER
 REOPEN_SECS                                        NUMBER
 DELAY_MINS                                         NUMBER
 NET_TIMEOUT                                        NUMBER
 PROCESS                                            VARCHAR2(10)
 REGISTER                                           VARCHAR2(3)
 FAIL_DATE                                          DATE
 FAIL_SEQUENCE                                      NUMBER
 FAIL_BLOCK                                         NUMBER
 FAILURE_COUNT                                      NUMBER
 MAX_FAILURE                                        NUMBER
 ERROR                                              VARCHAR2(256)
 ALTERNATE                                          VARCHAR2(256)
 DEPENDENCY                                         VARCHAR2(256)
 REMOTE_TEMPLATE                                    VARCHAR2(256)
 QUOTA_SIZE                                         NUMBER
 QUOTA_USED                                         NUMBER
 MOUNTID                                            NUMBER
 TRANSMIT_MODE                                      VARCHAR2(12)
 ASYNC_BLOCKS                                       NUMBER
 AFFIRM                                             VARCHAR2(3)
 TYPE                                               VARCHAR2(7)

En 10.2 la vue V$ARCHIVE_DEST à d'autres nouveau champs : MAX_CONNECTIONS, VALID_NOW , VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME et VERIFY

STATUS	Valid	Enabled	Active	Signification
VALID	True	True	True	L'utilisateur à proprement initialiser la destination, qui est disponible pour l'archivage.
INACTIVE	False	n/a	n/a	L'utilisateur n'a pas fournis ou il a supprimer l'information sur la destination.
ERROR	True	True	True	Une erreur s'est produite en créant ou en éxrivant dans le fichier de destination. voir l'erreur.
FULL	True	True	False	La destination plein.
DEFERRED	True	False	True	L'utilisateur à manuellement et temporairement désactiver la destination.
DISABLED	True	False	False	L'utilisateur à manuellement et temporairement désactiver la destination suite à une erreur. Voir l'erreur.
BAD PARAM	n/a	n/a	n/a	Une erreur de paramètre à eu lieu, voir l'erreur.

Le paramètre d'initialisation LOG_ARCHIVE_DEST_STATE_n (n un entier entre 1 et 10) nous permet de contrôler l'état de la disponibilité d'une destination (n) spécifique.

ENABLED : indique que la base peut utiliser la destination.

DEFER : indique que cette location est temporairement désactivée.

ALTERNATE : indique que cette destination est alternée

II.7. Mode de transmission d'un journal

Les deux modes pour transmettre les archivelogs dans leurs déstinations sont : normal archiving transmission et standby transmission. La transmission normal concerne la transmission des fichiers dans des disques locaux. Standby transmission concerne la transmission des fichiers à travers le reseau soit en local ou remote dans une base standby

II.7.1. Mode de transmission normal

En mode de transmission normal, La destination de l'archive est un autre disque du serveur de la base. Dans cette configuration, l'archive n'est plus concurrent avec les autres fichiers réclamés par l'instance et peut finir rapidement. Il faut spécifier la destination soit avec LOG_ARCHIVE_DEST_n ou LOG_ARCHIVE_DEST.

Pour la bonne pratique, il faut toujours sauvegarder les fichiers redo archivés dans un support de stockage comme les bandes. Le rôle primordial des fichiers redo archivés est la restauration.

II.7.2. Mode transmission standby

En mode de transmission standby, la destination de l'archive est soit en local ou en base standby distante.

Si nous manipulons notre base standby en mode managed recovery, nous pourrons conserver notre base standby synchronisé avec notre base source en appliquant automatiquement les redo archivés transmis.

Pour transmettre les fichiers avec succès à la base standby, soit ARCn ou le processus serveur doit faire ce qui suit :

Identifier l'emplacement distant.
Transmettre les journaux archivés ensemble avec le processus RFS (remote file server) qui réside dans le serveur distant.

Chaque processus ARCn à son correspondant RFS pour chaque destination standby. Par exemple, si trois processus ARCn sont archivés dans deux bases standby, alors Oracle établi six connections RFS.

On transmis les journaux archivés à travers le réseau vers un emplacement distant en utilisant les Services Oracle Net. L'archive distant est indiqué en spécifiant au nom du service Oracle Net comme un attribut de la destination. La base Oracle traduit alors le nom du service, par le fichier tnsnames.ora, pour connecter le descripteur. Le descripteur contient l'information nécessaire pour se connecter à la base distante. Le nom du service doit avoir le SID de la base, de telle façon à ce que la base met à jours correctement la section log history dans le fichier de contrôle pour la base standby.

Le processus RFS, qui s'exécute dans le nœud de destination, agi comme un serveur réseau au client ARCn. Essentiellement, ARCn envoi l'information au RFS, qui la transmis à la base standby.

Le processus RFS, qui est réclamé quand on archive dans une destination distante, est responsable des taches suivantes :

Consommer les E/S réseau depuis les processus ARCn.
Créer des noms de fichiers dans la base standby en utilisant le paramètre STANDBY_ARCHIVE_DEST.
Peupler les fichiers journaux dans le site distant.
Mettre à jours le fichier de contrôle de la base standby ( pour que le Recovery Manager l'utilise pour la restauration).

Les fichiers redo archivés sont essentiels pour maintenir une base standby, qui est une réplique exacte de la base. Nous pourrons fonctionner notre base mode archive standby, qui mis à jours automatiquement la base standby avec les fichiers redo archivés depuis la base d'origine.

On peut maintenir une base standby dans un disque local, mais Oracle encourage fortement de maximiser la protection contre un désastre en conservant la base standby dans un site distant.

II.8. Gestion des pannes des destinations archives

Le paramètre facultatif LOG_ARCHIVE_MIN_SCCEED_DEST détermine le nombre minimum de destinations à laquelle la base doit archivé les groupes redo avec succès avant qu'elle doive réutiliser les fichiers redo en ligne. La valeur par défaut est 1. Les valeurs valides pour n sont 1 et 2 si on utilise le duplexage ou 1 à 10 si on utilise le multiplexage.

Le paramètre LOG_ARCHIVE_DEST_n nous permet de spécifier si la destination est OPTIONAL (par défaut) ou MANDATORY. Le paramètre LOG_ARCHIVE_MIN_SUCCEED_DEST utilise toutes les destinations MANDATORY plus quelques destinations OPTIONAL non-standby pour déterminer si LGWR peut mettre à jours le journal en ligne. Les règles suivantes s'appliquent :

Omettre l'attribut MANDATORY pour une destination est la même que de spécifier OPTIONAL
On doit avoir au minimum une destination en locale, pour qu'on déclare OPTIONAL ou MANDATORY
Quand on spécifie une valeur à LOG_ARCHIVE_MIN_SUCCEED_DEST, Oracle devrait traiter au minimum une destination en locale comme MANDATORY, car la valeur minimum pour LOG_ARCHIVE_MIN_SUCCEED_DEST est 1.

Si une destination MANDATORY échoue, contenant une destination standby MANDATORY, Oracle ignorera le paramètre LOG_ARCHIVE_MIN_SUCCEED_DEST.

La valeur du paramètre LOG_ARCHIVE_MIN_SUCCEED_DEST ne peut pas être plus grand que le nombre de destinations, non plus que le nombre de destination MANDATORY plus le nombre de destinations local OPTIONAL.

Si on DEFER une destination MANDATORY, et la base met un journal redo en ligne sans transférer le log archivé dans le site standby, alors on doit transférer le log au standby manuellement.

Si on duplexe les fichiers redo archivés, on peut établir quelles destinations sont obligatoires ou facultatives en utilisant les paramètres LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST. Les règles suivantes s'appliquent :

Toute destination déclarée par LOG_ARCHIVE_DEST est obligatoire.
Toute destination déclarée par LOG_ARCHIVE_DUPLEX_DEST est facultative si LOG_ARCHIVE_MIN_SUCCEED_DEST = 1 et obligatoire si LOG_ARCHIVE_MIN_SUCCEED_DEST = 2.

On peut voir la relation entre les paramètres LOG_ARCHIVE_DEST_n et LOG_ARCHIVE_MIN_SUCCEED_DEST plus facilement dans le scénario suivant :

Dans ce scénario, on archive trois destinations en local, et dans chacun d'eux on déclare OPTIONAL. Le tableau suivant illustre les valeurs possibles du LOG_ARCHIVE_MIN_SUCCEED_DEST.

Ce scénario nous montre quand même de ne pas fixer explicitement n'importe quelles destinations à MANDATORY en utilisant le paramètre LOG_ARCHIVE_DEST_n, la base doit archivé avec succès dans un ou plusieurs emplacements quand LOG_ARCHIVE_MIN_SUCCED_DEST est fixé à 1,2 ou 3.

Considérons les cas suivants :

On spécifie deux destinations MANDATORY.
On spécifie deux destinations OPTIONAL
Aucune destination dans la base standby.

Ce tableau montre les valeurs possibles pour LOG_ARCHIVE_MIN_SUCCEED_DEST=n. Ce cas montre que la base doit être archivée dans les destinations spécifiées par MANDATORY, sans soucier si on fixe LOG_ARCHIVE_MIN_SUCCEED_DEST pour archiver dans des petits nombres de destinations.

Il faut utiliser l'attribut REOPEN du paramètre LOG_ARCHIVE_DEST_n pour spécifier si et ou ARCn devait tenter pour réarchiver dans une destination échoué suivant l'erreur. REOPEN s'applique pour toutes les erreurs, non seulement au erreurs OPEN.

REOPEN=n, fixe le nombre minimum de secondes avant ARCn devrait essayer pour rouvrir une destination défaillie. La valeur par défaut de n est 300 secondes. Une valeur 0 est la même d'enlever l'attribut REOPEN ; ARCn ne tentera pas d'archiver après la défaillance. Si on ne spécifie pas la clé REOPEN, ARCn recommencera plus à ouvrir la destination si erreur.

On ne peut pas utiliser REOPEN pour spécifier le nombre de tentative que ARCn devrait faire pour rejoindre et transférer les fichiers redo archivés.

Quand on spécifie REOPEN pour une destination OPTIONAL, Oracle peut mettre à jours les journaux s'il y'a erreur. Si on spécifie REOPEN pour une destination MANDATORY, Oracle décline la base de production quand il n'arrive pas à l'archiver. ans cette situation, on considère les options suivantes :

Archiver manuellement dans la destination défaillie.
Modifier la destination en différant la destination, on spécifie la destination comme facultatif ou on modifie le service.
Supprimer la destination.

Quand on utilise le mot clé REOPEN on' a :

ARCn rouvre la destination seulement quand on démarre une opération d'archive depuis le début du fichier redo, jamais durant une opération en cours. ARCn toujours essaye de copier les journaux depuis le début.
Si on spécifie REOPEN, soit avec un temps spécifique par défaut, ARCn vérifie pour voir si l'heure des erreurs enregistrées plus l'intervalle REOPEN est plus petit que l'heure actuelle. Si c'est ça, ARCn essaye de copier les journaux.
La clause REOPEN affecte avec succès l'état de la destination ACTIVE=TRUE. Les états VALID et ENABLED ne sont pas modifiés.

II.9. Trace du processus d'archivage

Les processus Background écrivent toujours dans les fichiers de trace quand c'est nécessaire. Dans le cas du processus d'archive, nous pouvons contrôler la sortie produite dans le fichier de trace, en fixant le paramètre d'initialisation LOG_ARCHIVE_TRACE par un niveau de trace. Cette valeur peut être spécifie comme suit :

Niveau de Trace	Signification
0	Désactive la trace des fichiers redo archivés. Par default.
1	Piste l'archivage du fichier redo.
2	Piste la statu de l'archivage pour chaque destination du fichier redo archivés.
4	Piste la phase opérationnel de l'archivage.
8	Piste l'activité de la destination des fichiers redo archivés.
16	Piste l'activité détaillé de la destination des fichiers redo archivés.
32	Piste les modifications du paramètre de destinations des fichiers archivés.
64	Piste l'activité de l'état du process ARCn.
128	Piste les activités du serveur FAL (fetch archived log).
256	Pour une release futur.
512	Piste l'activité asynchrone du LGWR.
1024	Piste le client physique RFS.
2048	Piste le heartbeat du ARCn/RFS .
4096	Piste en temps réel.

Nous pouvons combiner les niveaux de tracement en spécifiant une valeur égale à la somme des niveaux individuellement. Par exemple :

LOG_ARCHIVE_TRACE=12

Produit un fichier trace de niveau 8 et 4. Nous pourrons fixer différentiels valeurs pour une base primaire et une base standby.

La valeur par défaut du paramètre LOG_ARCHIVE_TRACE est 0. A ce niveau, Le processus archivelog génère les alertes appropriées.

On peut modifier la valeur de ce paramètre dynamiquement en utilisant la commande ALTER SYSTEM. La base doit être montée mais non ouverte. Par exemple :

ALTER SYSTEM SET LOG_ARCHIVE_TRACE=12;

A cette manière, la modification prend effet au démarrage de la base à la prochaine opération d'archivage.

II.10. Informations sur les vues des fichiers redo archivés

On peut afficher des informations concernant les fichiers redo archivés en utilisant :

Les vues dynamique
La commande ARCHIVE LOG LIST

II.10.1. Les vues dynamique

Il existe plusieurs vues qui nous donnent des informations sur les fichiers redo archivés comme :

V$LOG
V$DATABASE
V$ARCHIVED_LOG
V$ARCHIVE
V$ARCHIVE_GAP
V$ARCHIVE_PROCESSES
V$ARCHIVE_DEST
V$ARCHIVE_DEST_STATUS

Par exemple pour savoir le fichier redo qui doit être archivé, on lance la commande suivante :

SQL> SELECT GROUP#, ARCHIVED FROM SYS.V$LOG;

    GROUP# 	ARC
     -----------	------
         1 		YES
         2 		YES
         3 		NO

Pour Savoir si la base est en mode ARCHIVELOG :

SELECT LOG_MODE FROM SYS.V$DATABASE;
LOG_MODE
------------
NOARCHIVELOG

II.10.2. La commande ARCHIVE LOG LIST

La commande ARCHIVE LOG LIST affiche des informations sur las archives de l'instance connecté. Par exemple :

SQL> ARCHIVE LOG LIST
mode Database log                              mode No Archive
Archivage automatique                          Désactivé
Destination de l'archive                       USE_DB_RECOVERY_FILE_DEST
Séquence de journal en ligne la plus ancienne     82
Séquence de journal courante                      84

En cours, Je cite les autres options de la commande ARCHIVE LOG

III. Le Redo Log Buffer

En cours. Il n y'a pas beaucoup de chose à dire sur le redo log buffer. Par contre je parlerai un peit peu sur les latchs.

IV. Checkpoint

Le mot Checkpoint signifie la synchronisation des données modifiées en mêmoire avec les fichiers de données dans la base. Par intervalle, le fait d'écrire les données modifiées dans les fichiers de données entre les checkpoints assure la disponibilité d'une quantité de mémoire, qui améliorera les performances pour trouver de la mémoire libre pour les opérations suivantes. Le mécanisme d'écritures des blocs modifiés dans le disque n'est pas synchronisé avec le commit des transactions.

Le checkpoint doit s'assurer que toutes les modifications des tampons dans la cache sont réellement écrites dans les fichiers de données correspondants.

Le checkpoint se réalise sous quatre types d'évènements :

Quand le delai de LOG_CHECKPOINT_TIMEOUT est atteint.
Quand la taille en byte de (LOG_CHECKPOINT_INTERVALL * taille d'E/S des blocs OS) est écrite dans le fichier redo en cours.
Directement par la commande ALTER SYSTEM SWITCH LOGFILE.
Directement par la commande ALTER SYSTEM CHECKPOINT.

Le checkpoint doit être rompus dans deux cas spécifiques :

Le DBWR écrit les tampons modifiés de la cache dans les fichiers de données.
Le LGWR met à jours l'entête des fichiers de données et le fichier de contrôle.

Quand LGWR effectue cette tâche, il ne peut pas faire son travail normalement, qui consiste à écrire les transactions dans les fichiers redo. Un process spécifique CKPT doit être utiliser pour liberer le LGWR de cette tâche. A partir de la version Oracle8 le process CKPT démarre automatiquement.

Le mécanisme de checkpoints présente un dilemme pour les dba Oracle, qui doivent trouver un point de compromis entre une performance global de l'instance et la rapidité de la restauration. La durée de restauratement est directement lié à la frequence des checkpoints.

Plus il y'a de checkpoints, plus la restauration est rapide. La restauration dépend de la quantité écrite dans le fichier redo depuis le dernier checkpoint.

Quand une restauration est nécessaire suite à un crash de l'instance, seulement les transactions écrites depuis le dernier checkpoint qui sont appliqués. Suivant le contexte, on a le choix entre la sécurité avec des checkpoints fréquents et un temps de restauration court ou une performance globale de l'instance avec des checkpoints moins fréquents. Normalement la majorité préfère la performance, car elle représente l'activité majeure dans une base de production.

Il y'a deux types de checkpoints :

Checkpoint normal
Checkpoint incremental

Le checkpoint normal met à jours les fichiers de contrôle et les entêtes des fichiers de données

Le checkpoint incremental met à jours seulement le fichier de contrôle.

IV-A. Les paramètres de checkpoint

IV-A-1. Avant la 10g

Voir l'article sivant : Avant la 10g

IV-A-2. Le paramètre FAST_START_MTTR_TARGET

Dans 10g, Oracle à introduit le Conseiller Calibrage des Fichiers Redo qui est recommandé pour tailler les fichiers redo en limitant les log switchs démesurés, les checkpoints excessifs et incomplète, le problème d'archive, la performance du DBWR et les E/S excessif du disque. Dans 10g on peut spécifier à travers le paramètre FAST_START_MTTR_TARGET seulement la durée de la restauration de la base suite à un crash. La fixation de ce paramètre déclenchera le conseiller calibrage des fichiers redo et proposera la taille optimale pour les fichiers redo. On peut utiliser la valeur en Mega de la colonne OPTIMAL_LOGFILE_SIZE dans la vue V$INSTANCE_RECOVERY pour reconstruire les groupes des fichiers redo :

SQL>  SELECT OPTIMAL_LOGFILE_SIZE FROM V$INSTANCE_RECOVERY;
 
OPTIMAL_LOGFILE_SIZE 
--------------------
64

V-B. En cours

Ici c'est plus interessant, je vais détaillé la structure interne de la file d'attente Checkpoint, qui va me servir pour un prochain article sur la structure interne du buffer cache.

V. Reglages des fichiers redo et du redo log buffer

V-A. log file switch completion

Dans Oracle 10g, L'événement d'attente log file switch completion fait partie de la classe Configuration. Il faut toujours tenir compte des considérations suivantes :

Les log switch excessif provoqué par des petites tailles de fichiers redo et les transactions, produit beaucoup d'entrées redo.

Si une session passe beaucoup de son temps de traitements à attendre dans l'événement log file switch completion, c'est parce que la taille des fichiers redo sont petites par rapport à la quantité d'entrées redo qui se reproduisent, provoquant de nombreux log switch. La session Oracle attend constamment que le processus LGWR termine l'écriture dans le fichier redo en cours et d'ouvrir de nouveau un autre fichier redo.

Le temps d'attente de l'évènement log file switch completion peut être diminuer ou éliminer en réduisant le nombre de log switch. Cela signifie qu'on a besoin de créer de nouveaux groupes de fichiers redo assez grand et supprimer les anciens groupes. Un fichier redo assez grand diminuera le nombre de switch log et les checkpoints classiques qui sont très coûteux.

Quelle est la taille du fichier redo ?

La réponse dépend de la taille du fichier redo en cours, le taux actuel de switch log et l'objectif fixé en nombre de log switch par heure pendant les traitements. Pour trouver la fréquence des log switch en utilise la requête données dans la section log buffer space. Si notre objectif est de 4 fichiers redo par heure au lieu de 60 et que la taille du fichier redo en cours est de 20M, alors le nouveau fichier redo devrait avoir une taille de 300M (60*20M/4).

Les fichiers redo assez grands ont pour résultats un temps de restauration assez long. Oracle fournit le paramètre FAST_START_MTTR_TARGET pour entretenir le temps de restauration suite à un crash en réglant le lancement des checkpoints (depuis Oracle 9i) . Dans Oracle 8i, on utilise le paramètre FAST_START_IO_TARGET. Et dans les versions antérieures, on règle les checkpoints avec les paramètres LOG_CHECKPOINT_INTERVAL et LOG_CHECKPOINT_TIMEOUT.

V-B. log file switch (checkpoint incomplete)

Dans 10g, l'événement d'attente log file switch (checkpoint incomplete) fait partie des classes Configuration. Il faut toujours tenir compte des considérations suivantes :

Les log switch excessif sont provoqués par de petites tailles de fichiers redo et un taux très élevé de transaction.

Le log file switch (checkpoint incomplete) et le log file switch completion sont deux évènements très proches et partagent la même cause, c'est à dire, la taille des fichiers redo sont assez petites par rapport à la quantité des entrées redo qui sont produites. Quand on a l'un de ces évènements, normalement on a l'autre. Dans ce cas, les processus foreground attendaient le processus DBWR au lieu d'attendre le processus LGWR. Cela arrive, quand une application produit beaucoup d'entrées redo, tellement que le processus LGWR n'arrive plus à recycler les fichiers redo car le DBWR n'a pas encore fini de copier les blocs modifiés. Le processus LGWR ne peut pas sur écrire ou passer le prochain fichier redo, car le checkpoint est incomplet. La solution est d'augmenter la taille des fichiers redo et d'ajouter d'autres groupes.

V-C. L'attente de l'évènement log file sync

Dans 10g, l'événement d'attente log file sync fait partie des classes Configuration. Il faut toujours tenir compte des considérations suivantes :

L'événement log file sync est relatif à l'arrêt des transactions (commit ou rollback).
Quand un processus passe beaucoup de temps sur l'événement log file sync, il indique généralement de nombreux commits ou des transactions assez brèves.

Oracle enregistre les transactions et les blocs modifiés dans le log buffer. Le processus LGWR est responsable de liberer la place dans le log buffer en écrivant le contenu du log buffer dans les fichiers redo :

Toutes les trois secondes.
Quand la taille du log buffer est 1/3 pleins ou il a 1M d'entrées redo.
Quand un utilisateur valide ou annule une transaction.
Quand il est signalé par le process DBWR.

Les écritures initiées par des validations ou des annulations utilisateurs sont connues sous le nom d'écritures synchrone ; il se peut qu'un processus utilisateur effectue une grande transaction qui génère beaucoup d'entrées redo ce qui déclenchera le processus LGWR à exécuter des écritures background, mais la session de l'utilisateur n'attendra jamais que les écritures background se terminent. Toutefois, au moment où la session utilisatrice valide ou annule sa transaction et le paramètre _WAIT_FOR_SYNC est à TRUE, le processus poste le LGWR et attends dans l'événement log file sync pour que le processus flashe les entrées redo en cours, inclus le marqueur commit, dans les fichiers redo. Durant la synchronisation de ces logs, le processus LGWR attend en faveur d'une écriture synchrone pour terminer dans l'événement log file parallel write tandis que la session utilisatrice attends en faveur d'un processus de synchronisation pour terminer dans l'événement log file sync.

Une fois le process entre dans l'attente log file sync, il y'aura deux possibilités pour sortir. L'un, est quand le process foreground est posté par LGWR quand la synchronisation log est achevée. L'autre, est quand l'attente à fait une pause ( typiquement en 1 seconde), at which point le process foreground vérifie le log SCN courant pour déterminer si ces commit ont était effectué dans le disque. Si c'est arrivé, le process continue le traitement, sinon le process re-entre l'attente.

Il ne faut jamais modifier le paramètre _WAIT_FOR_SYNC à FALSE, même pas dans une base de développement ou une base de test, car les transactions validées ne sont plus garanties d'être restaurer suite à une défaillance instance. Certains personne l'utilise pour tricher sur les benchmarks.

Typiquement, L'attente log file sync est un événement sans incident. Il est bref et à peine perceptible par l'utilisateur final. Pourtant, une multitude de ces attentes peut contribuer à des temps de réponses longues et trace des statistiques dans les vues V$SYSTEM_EVENT et V$SESSION_EVENT. Utiliser cette requête pour trouver les sessions en cours qui passent la plupart de leurs traitements à attendre dans l'événement log file sync depuis l'ouverture de la session. Evaluer le TIME_WAITED avec USER_COMMIT et HOURS_CONNECTED. Pour découvrir qui exécute beaucoup de commit entre deux points spécifiques dans le temps, on peut calculer le delta en utilisant l'exemple suivant :

select a.sid,
       a.event,
       a.time_waited,
       a.time_waited / c.sum_time_waited * 100 pct_wait_time,
       d.value user_commits,
       round((sysdate - b.logon_time) * 24) hours_connected
from   v$session_event a, v$session b, v$sesstat d,
       (select sid, sum(time_waited) sum_time_waited
        from   v$session_event
        where  event not in (
                    'Null event',
                    'client message',
                    'KXFX: Execution Message Dequeue - Slave',
                    'PX Deq: Execution Msg',
                    'KXFQ: kxfqdeq - normal deqeue',
                    'PX Deq: Table Q Normal',
                    'Wait for credit - send blocked',
                    'PX Deq Credit: send blkd',
                    'Wait for credit - need buffer to send',
                    'PX Deq Credit: need buffer',
                    'Wait for credit - free buffer',
                    'PX Deq Credit: free buffer',
                    'parallel query dequeue wait',
                    'PX Deque wait',
                    'Parallel Query Idle Wait - Slaves',
                    'PX Idle Wait',
                    'slave wait',
                    'dispatcher timer',
                    'virtual circuit status',
                    'pipe get',
                    'rdbms ipc message',
                    'rdbms ipc reply',
                    'pmon timer',
                    'smon timer',
                    'PL/SQL lock timer',
                    'SQL*Net message from client',
                    'WMON goes to sleep')
        having sum(time_waited) > 0 group by sid) c
where  a.sid         = b.sid
and    a.sid         = c.sid
and    a.sid         = d.sid
and    d.statistic#  = (select statistic# 
                        from   v$statname 
                        where name = 'user commits')
and    a.time_waited > 10000
and    a.event       = 'log file sync'
order by pct_wait_time, hours_connected;

 SID EVENT         TIME_WAITED PCT_WAIT_TIME USER_COMMITS HOURS_CONNECTED
---- ------------- ----------- ------------- ------------ ---------------
 423 log file sync       13441    84.9352291        62852              15
 288 log file sync       13823    85.3535042        63007              15
 422 log file sync       13580    85.7648099        62863              15
 406 log file sync       13460    87.0239866        62865              15
 260 log file sync       13808    87.0398386        62903              15

Dans un environnement RAC, le process background LMS doit enregistrer les attentes dans l'événement log file sync. Cala à cause du mécanisme write ahead logging. Quand un process foreground demande un bloc depuis une autre instance, toutes les entrées redo associé avec le bloc doit être flashé dans le disque avant le transfert du bloc. Dans ce cas, le process background LMS lance la synchronisation de log et attend dans l'événement log file sync.

V-A-1. fréquence très élevée des validations

Parmi les causes de l'attente log file sync est la fréquence très élevée des validations (commit). Il faut trouver si la session qui passe plus de temps dans l'événement log file sync appartient à un batch ou à un processe OLTP ou si c'est un middle-tier (comme Tuxedo, Weblogics, etc.)

Si la session appartient à un process batch, il doit être validé à chaque modification de la base à l'intérieur d'un loop. Découvrir le nom du module et demander au développeur e revoir dans leurs codes si les nombres de commit peut être diminués. C'est un problème d'applications, et la solution est simplement d'éliminer les validations non nécessaires et réduire la fréquence des validations.

Certains developpeurs d'applications ont appris que s'ils valident rarement, les jobs devrait s'échouer suite au manque d'espace dans les segements d'annulations, t on peut être appelé à minuit.

Introduire des validations supplémentaire peut créer d'autres problèmes, parmis eux, la fameuse ORA-01555: l'erreur snapshot too old car l'annulation (ou undo) des données peuvent être sur écrite. Une frequence de commit trops elevé augmente aussi le temps système qui est associé avec le démarrage et la fin des transactions. Au début de chaque transaction, Oracle assigne un segement d'annulation (appelé segement d'annulation imposé) et mets à jours la table de transaction dans l'entête du segement d'annulation. la table de transaction doit être aussi mis à jours à la fin de chaque transactions, suivi par une validation de l'activitée de netoyage. Mettre à jours l'entête du segement d'annulation doit aussi être enregistré dans le log buffer car le bloc à été modifié. Pourtant, le fait de valider à la fin d'une unité de travail resoudera le problème. Le commit dans un loop à besoin d'être enlevé de telle façon que le commit d'un travail se fasse à la fin.

Si la session qui passe beaucoup de temps dans l'événement log file sync est une connexion persistance d'une couche middle-tier, alors c'est un cas difficile car il servit plusieurs utilisateurs frontaux. On doit tracer la session avec l'événement 10046 et observer le comportement de l'application. Chercher l'événement log file sync dans le fichier trace. Ils nous donneront une idée sur la fréquence des validations. Alternativement, on peut creuser les fichiers redo par le Logminer. Cela montrera le comportement des validations dans le système.

Dans une base OLTP, on observe normalement, un temps d'attente élevé du log file sync au niveau système (V$SYSTEM_EVENT) mais pas au niveau session. Le temps d'attente élevé au niveau système doit être mené par des petites transactions des sessions OLTP qui sont se connecte et se déconnecte activement dans la base. Si c'est notre scénario, le seule chose que nous pourrons faire est d'assurer un circuit stable d'E/S pour le process LGWR. Cela inclus l'utilisation les E/S/ asynchrones et mettre les fichiers redo dans des périphériques RAW ou un équivalent, comme Veritas Quick I/O, cela est servi par des contrôleurs E/S dédié ou mieux encore, utiliser des disques performants pour les fichiers redo.

V-A-2. E/S lent

Examiner la vue V$SYSTEM_EVENT comme il suit pour découvrir le temps d'attente moyen de LGWR (événement log file parallel write). Le temps d'attente moyenne de 10ms (1cs) ou inférieur est généralement acceptable.

select * 
from   v$system_event 
where  event in ('log file sync','log file parallel write'); 

EVENT                    TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT
------------------------ ----------- -------------- ----------- ------------
log file parallel write      6411138              0     3936931   .614076783
log file sync                6597655           9819     6534755    .99046631

Un débit trop élevé d'E/S dans un système peut améliorer la moyenne du temps d'attente des évènements log file sync et log file parallel write. Pourtant, ce n'est pas une excuse de ne pas régler l'application si elle est mal conçue et valide fréquemment. On doit tenter de bien chercher la couche de la base et l'E/S du sous-système, peut être-il est difficile de traiter avec un groupe d'application ou une application third-party. Toutefois, parce qu'est une application third-party ne donne pas au vendeur le droit lancer des codes bric-à-brac dans la base. A savoir qu'on ne peut pas résoudre ce genre de problème applicatif. Chaque modification effectuée par notre soin dans la base donnera l'impression à l'utilisateur que c'est un problème de la base.

Il y'a plusieurs choses qu'on peut fournir avec l'aide de l'administrateur système concernant l'attente log file sync en augmentant le débit d'E/S des fichiers redo. Cela inclus l'utilisation des connexions fibre optique (FC) au bases sous SAN (storage area network), Ethernet gigabit (Gig-E) ou des connexions en Bande Infini à la base sous NAS (network attached storage), SCSI utltrawide ou des connexions FC à au bases sous DAS (direct attached storage) ; reseaux privés ; switches à haut-vitesse ; contrôleurs d'E/S dédié ; E/S asynchrones ; Placer les fichiers redo dans des péréphiriques RAW et lier le LUN dans RAID 0 ou 0+1 à la place de RAID 5, et ainsi de suite.

V-A-3. Log Buffer trop grand

Suivant l'application, un log buffer surdimensionné (plus grand que 1M) peut étendre les attentes log file sync. Un log buffer large réduit le nombre d'écritures background et permet au processe LGWR d'être paresseux et provoque beaucoup d'entrées redo de s'accumuler dans le log buffer. Quand un processe valide, le temps d'écriture synchrone ne devrait pas être long car le processe LGWR à besoin de copier beaucoup d'entrées redo. La taille de notre log buffer ne devrait pas être petit, cela provoquerai les sessions à servir l'évènement log buffer space plus ou moins grand ce qui prolongera les attentes log file sync. D'une part, on veut un log buffer assez large pour faire face aux demandes d'espaces du log buffer durant la génération explosive des redo, surtout immédiatement après un log switch. D'autre part, on veut un log buffer assez petit pour augmenter les écritures background et réduire le temps d'attente du log file sync. Pour satisfaire les deux demandes, c'est le paramètre _LOG_IO_SIZE, qui est par défaut le 1/3 du LOG_BUFFER ou 1mb, peu importe si c'est inférieur. C'est l'un des seuils qui signale au process LGWR de commencer à écrire. En d'autres mots, on peut avoir un log buffer assez large, mais un _LOG_IO_SIZE assez petit devrait augmenter les écritures background, qui à la suite réduit le temps d'attente log file sync. Beaucoup d'activités de LGWR mat une lourde charge dans les latches redo copy et redo writing. Voir l'événement d'attente log file parallel write.

Par défaut, le paramètre _LOG_IO_SIZE est réduit à 1/6 de la taille du LOG_BUFFER dans Oracle 10g. Car la valeur par défaut du paramètre _LOG_PARALLELISM_MAX est à 2 quand le paramètre COMPATIBLE est fixé à 10.0 ou plus. La valeur par défaut de _LOG_IO_SIZE dans Oracle 10g se calcule en divisant la taille du LOG_BUFFER avec la taille de bloc du journal (LEBSZ) et la valeur de kcrfswth, comme ici :

orcl> oradebug setospid 14883Oracle pid: 5, Unix process pid: 14883, image: oracle@aoxn1000 (LGWR)
orcl> oradebug unlimitStatement processed.
orcl> oradebug call kcrfw_dump_interesting_dataFunction returned 90F42748
orcl> oradebug tracefile_name/orahome/admin/orcl/bdump/orcl_lgwr_14883.trc
orcl> !grep kcrfswth /orahome/admin/orcl/bdump/orcl_lgwr_14883.trc   kcrfswth = 1706
orcl> select value from v$parameter where name = 'log_buffer';VALUE---------------5242880
orcl> select max(LEBSZ) from x$kccle;MAX(LEBSZ)----------       512
orcl> select 5242880/512/1706 from dual; 5242880/512/1706----------------      6.00234467

La valeur du paramètre PROCESSES assez large peut aussi augmenter les attentes log file sync. Durant chaque opération de synchronisation, le LGWR doit balayer la structures de données des processes pour découvrir les sessions qui attendent dans cet événement et ceux qui écrivent leurs redo dans le disque. Diminuer le nombre de processes peut aider à réduire les vastes attentes log file sync. Utiliser la vue V$RESOURCE_LIMIT comme guide. D'après Oracle, ce problème est résolu dans Oracle 9.2.

V-D. log file parallel write

L'évènement d'attente log file parallel write à trois paramètres : fichiers, blocs et demandes. Dans 10g cette évènement fait partie des classes des attentes E/S systèmes. Il faut tenir compte des ces trois clés s'il y a un évènement d'attente log file parallel write.

L'évènement log file parallel write concerne seulement le process LGWR.
Un LGWR lent, peut influencer le temps de commit du processe foreground.
Des attentes significatives du log file parallel write est susceptible d'être un sujet de E/S.

L'événement d'attente log file parallel write concerne seulement le process LGWR. Quand il est temps d'écrire, Le process LGWR écrit le redo buffer dans les fichiers de journalisation en ligne en lançant des séries d'appels écriture système dans l'OS. Le process LGWR attend en faveur des écritures pour terminer l'événement d'attente log file parallel write. Le process LGWR cherche les blocs redo pour les écrire toutes les trois secondes, pendant le commit, pendant le rollback, quand le seuil _LOG_IO_SIZE est atteint, quand 1M d'entrée redo est dans le log buffer et quand c'est signalé par le process DBWR.

Quoique les sessions utilisateurs n'influencent pas l'événement d'attente log file parallel write, elles peuvent avoir un impact en ralentissant le process LGWR. Un process LGWR lent, peut exalter les attentes log file sync, à laquelle les sessions utilisateurs attend durant les commits ou les rollbacks. Les sessions utilisateurs n'obtiendront pas une reconnaissance complète d'un commit ou d'un rollback jusqu'à ce que le LGWR à terminer son écriture.

Les statistiques clés de la base à tenir en compte sont TIME_WAITED et AVERAGE_WAIT des évènements d'attentes log file parallel write et log file sync :

SQL> select event, time_waited, average_wait from   v$system_event
 where  event in ('log file parallel write','log file sync');

EVENT                       TIME_WAITED     AVERAGE_WAIT
-------------------------   -----------    -------------
log file parallel write            1736             ,58
log file sync                       161             ,44

Si l'attente de l'évènement log file parallel write est plus grand que 10ms, cela indique normalement un débit lent d'E/S. Activer les écritures asynchrones si les redo logs sont dans des devices raw et si l'OS supporte les E/S asynchrones. Malheureusement, on ne peut pas utiliser plus qu'un seul process LGWR. Dans ce cas, il est nécessaire de ne pas surcharger Le point de montage et le contrôleur ou se trouve les fichiers de journalisation. Déplacer les fichiers de journalisation dans des disques rapides peut aussi aider. Il est fortement conseillé d'éviter de mettre les redo logs dans les disques RAID5.

En plus des améliorations du débit d'E/S, on peut diminuer la quantité des entrées redo. Si possible, utilisez l'option NOLOGGING. Les indexes devrait être crées ou reconstruis avec l'option NOLOGGING. Les opérations CTAS doivent utiliser aussi cette option.

L'option NOLOGGING ne s'applique pas à des opérations DML normal comme les insertions, les mises à jours et les suppressions. Les objets créent avec l'option NOLOGGING ne sont pas restaurés à moins qu'une sauvegarde à été faite avant la corruption. Une base en mode FORCE LOGGING devrait enregistrer dans les journaux toutes les modifications (excepté pour les tablespaces temporaire), sans soucier de la fixation des tablespaces et des objets.

Une fréquence basse de validation aux détriments de l'usage des segments d'annulations fourni aussi quelques soulagements. Une fréquence élevée de validation provoque le process LGWR d'être hyperactif et quand il est couplé avec débit d'E/S assez lent devrait seulement exagérer les attentes du log file parallel write. L'application qui doit traiter un grand ensemble de données dans un loop et valide chaque modification, provoquera le log buffer d'être flashé fréquemment. Dans ce cas, il faut modifier l'application pour qu'il valide moins fréquemment. Il peut y avoir aussi plusieurs sessions courtes qui se connecte à la base, exécutant des opérations DML rapide, et se déconnecte. Dans ce cas, le modèle de l'application doit être revu. On peut trouver ailleurs celui qui valide le plus fréquemment avec la requête suivante :

SQL> select sid, value from   v$sesstat where  statistic# = (select statistic#
where  name = 'user commits')order by value;

       SID      VALUE
---------- ----------
       142          0
       170          0
       151          0
       152          0
       154          0
       160          0
       146          0
       162          0
       163          0
       164          0
       165          0
       166          0
       167          0
       168          0
       169          0
       161        134

16 ligne(s) sélectionnée(s).

Une autre évidence des validations excessive est le gaspillage élevé des redo.

SQL> select b.name, a.value, round(sysdate - c.startup_time) days_old 
from   v$sysstat a, v$statname b, v$instance c
where  a.statistic# = b.statistic# 
and    b.name      in ('redo wastage','redo size');

NAME            VALUE       DAYS_OLD
-------------   --------    --------

redo size       36833328           0
redo wastage      912024           0

Vérifier le job scheduler pour voir si une sauvegarde à chaud à été lancé durant les heures de pointe. Il est capable de créer une grande quantité d'entrées redo, qui à la suite augmente l'attente du log file parallel write. Une sauvegarde à chaud devrait être lancé en dehors des heures de pointe.

A la fin, Il faut faire attention de ne pas charger le LGWR avec de nombreux entrées redo en même temps. Cela peut arriver avec un grand log buffer car le seul 1/3 est aussi grand et garde plus d'entrées redo. Quand le seuil 1/3 est atteint, le process LGWR accompli l'écriture background s'il n'est pas encore activé. Et la quantité des entrées redo doit être trop pour le process LGWR de traiter en une seule fois, provoquant le prolongement des attentes log file parallel write. Ainsi, l'idée est de verser les écritures LGWR. Cela peut être fait en diminuant le seuil 1/3, qui est contrôler par le paramètre d'initialisation _LOG_IO_SIZE. Par défaut _LOG_IO_SIZE est 1/3 du LOG_BUFFER ou 1MB, peu importe si c'est moins, exprimé en blocs de log. Requêter X$KCCLE.LENSZ pour avoir la taille du bloc d'un journal. Typiquement, c'est 512 bytes. Par exemple, si LOG_BUFFER est 2097152 bytes (2MB), et la taille du bloc journal est 512 bytes, alors la valeur par défaut de _LOG_IO_SIZE est 1365 de blocs de journal utilisés. A cette taille, le process LGWR devient paresseux et écrit normalement seulement à la fin des transactions (écritures synchrones) ou quand il se réveille de sa pause de 3 secondes. On devrait mettre _LOG_IO_SIZE à 64K. De cette façon, on peut calmer d'avoir un grand log buffer pour accorder les points de transitions pour l'espace tampon après les checkpoints, mais les écritures devraient démarrer quand il y'a 64K d'entrées redo dans le tampon, en supposant qu'il ni y a aucune validation ou annulation d'un utilisateur, et le LGWR en sommeil n'a pas écoulé son temps durant cette période.

Le LGWR écrit les opérations qui réclament les latches redo copy et redo writing. Ainsi, plus de processe LGWR actif devrait augmenter la charge de ces latches. Ne réduisez pas _LOG_IO_SIZE si ces latches s'endorment souvent. Pourtant, si la condition nous permet de modifier _LOG_IO_SIZE, nous devons surveiller son impact en requêtant la vue V$LATCH. Assurez-vous d'obtenir une marge pour appliquer la modification.

On peut utiliser la requête suivante pour trouver le nombre moyen de blocs redo log par écriture et le moyen de la taille d'E/S LGWR en bytes :

select round((a.value / b.value) + 0.5,0) as avg_redo_blks_per_write,
round((a.value / b.value) + 0.5,0) * c.lebsz as avg_io_size
from v$sysstat a, v$sysstat b, x$kccle c
where c.lenum = 1
and a.name = 'redo blocks written'
and b.name = 'redo writes';

AVG_REDO_BLKS_PER_WRITE AVG_IO_SIZE
----------------------- -----------
8 8192

VI. Le LOGMINNER

Ca sera un autre article. Je pense qu'il existe déja

VI-A. Introduction

VI-B. Configuration du Logminer

VI-C. Utilisation du Logminer

VI-D. La vue V$LOGMNR_CONTENTS

VI-E. DBMS_LOGMNR.START_LOGMNR

VIII. Dump des fichiers Redo

Les informations dans les fichiers redo sont souvent très utile pour diagnostiquer les problèmes de corruption.

On utilise les commandes suivantes :

La commande 'alter session' est utilisé pour décharger l'en-tête dur fichier redo.
On utilise 'alter system dump logfile' pour décharger le contenu du fichier redo.

Cette commande nécessite le privilège système ALTER SYSTEM. La base peut être en mode mount, nomount ou open quand la commande est lancé. Un fichier redo en ligne ou archivé peut être déchargé. Il est possible de faire un dump d'un fichier d'une autre base, tant que l'OS est le même.

La sortie de la commande est mise dans le fichier trace de la session.

Les differents façons pour faire un dump du fichier redo sont :

Dump basé sur le DBA (Data Block Address)
Dump basé sur le RBA (Redo Block Address)
Dump basé sur le temp
Dump basé sur la couche et l'opcode
Dump de l'entête du fichier redo
Dump du fichier redo en entier

A. Dump basé sur le DBA (Data Block Address)

Cela, déchargera tous les enregistrements redo dans un rangée de blocs de données specifié par file# et bloc#..

A partir de SQL, en lance la commande suivante :

ALTER SYSTEM DUMP LOGFILE 'filename'  
 DBA MIN fileno . blockno  
   DBA MAX fileno . blockno;

Exemple:

        ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
        DBA MIN 5 . 31125  
        DBA MAX 5 . 31150;

B. Dump basé sur le RBA (Redo Block Address)

Ici, on décharge tous les enregistrements redo entre deux adresses redo spécifiés par un numéro de séquence et un numéro de bloc.

ALTER SYSTEM DUMP LOGFILE 'filename'  
   RBA MIN seqno . blockno  
   RBA MAX seqno . blockno;

Example:

ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
   RBA MIN 2050 . 13255  
   RBA MAX 2255 . 15555;

C. Dump basé sur le temps

Cette option devrait provoquer la décharge des enregistrements redo crées entre deux dates.

Pour décharger le fichier redo suivant les dates, on utilise la commande suivante :

ALTER SYSTEM DUMP LOGFILE 'filename'  
   TIME MIN value  
   TIME MAX value;

Par exemple:

        ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V7323/dbs/arch1_76.dbf'  
        TIME MIN 299425687  
        TIME MAX 299458800;

La date est donnée dans la REDO DUMP TIME.

time = (((((yyyy - 1988)) * 12 + mm - 1) * 31 + dd - 1) * 24 + hh) * 60 + mi) * 60 + ss;

YYYY	année
mm	mois	01-12
dd	jours	01-31
hh	heure	00-23
mi	minute	00-59
ss	seconde	00-59

D. Dump basé sur la couche et l'opcode.

LAYER and OPCODE sont utilisés pour décharger tous les enregistrements d'un type particulier.

Depuis la commande SQL :

ALTER SYSTEM DUMP LOGFILE 'filename'  
   LAYER value  
   OPCODE value;

Par exemple:

        ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
        LAYER 11  
        OPCODE 3;

E. Dump des informations de l'entête du fichier

Cette commande décharge les informations des entêtes de tous les fichiers redo en ligne.

A partir de SQL :

   alter session set events 'immediate trace name redohdr level 10';

La commande décharge les entêtes de tous les fichiers journaux

DUMP OF LOG FILES: 3 logs in database
LOG FILE #1: 
  (name #3) D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO01.LOG
 Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x19000 seq: 0x00000053 hws: 0x4 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00315ef2
 Low scn: 0x0000.0031b9a8 10/23/2005 00:40:37
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
 FILE HEADER:
	Compatibility Vsn = 169869568=0xa200100
	Db ID=1483236283=0x586863bb, Db Name='B10G2'
	Activation ID=1483223739=0x586832bb
	Control Seq=2084=0x824, File size=102400=0x19000
	File Number=1, Blksiz=512, File Type=2 LOG
 descrip:"Thread 0001, Seq# 0000000083, SCN 0x00000031b9a8-0xffffffffffff"
 thread: 1 nab: 0xffffffff seq: 0x00000053 hws: 0x4 eot: 1 dis: 0
 reset logs count: 0x21d964be scn: 0x0000.00085bc4
 Low scn: 0x0000.0031b9a8 10/23/2005 00:40:37
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
 Enabled scn: 0x0000.00085bc4 09/01/2005 20:40:30
 Thread closed scn: 0x0000.0031fb40 10/23/2005 08:58:17
 Disk cksum: 0x5c30 Calc cksum: 0x5c30
 Terminal Recovery Stop scn: 0x0000.00000000
 Terminal Recovery Stamp  01/01/1988 00:00:00
 Most recent redo scn: 0x0000.00000000
 Largest LWN: 0 blocks
 Miscellaneous flags: 0x0
 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000

* DUMP OF LOG FILES: 3 logs in database

La ligne suivante montre que la base à 3 fichiers de journalisation.

* LOG FILE #1:
(name #3) D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO01.LOG

C'est le nom du fichier de journalisation avec le chemin complet.

* Thread 1 redo log links: forward: 2 backward: 0 siz: 0x19000 seq: 0x00000053 hws: 0x4 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00315ef2 Low scn: 0x0000.0031b9a8 10/23/2005 00:40:37 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00

Ces informations se trouve dans le fichier de contrôle.

Ici on'a deux informations intéressantes pour calculer la taille du fichier redo : siz et bsz.

Bsz est la taille d'un bloc et siz est le nombre de blocs dans le fichier redo.

Dans cette exemple la taille du fichier redo exacte est 52429312 (taille OS, on peut le verifier par les commandes OS comme ls sous unix ou dir sous dos).

D'après le fichier trace la taille du fichier redo est egale à siz x bsz = 102400 x 512 = 52428800 (car 0x19000 est égale à 102400 en décimal). Et on remarque qu'il manque un bloc 52429312 - 52428800 = 512 . Tout simplement le bloc manquant est celui de l'entête du fichier redo qui contient des informations OS. Enfin, la taille exacte du fichier est (siz + 1) x bsz.

seq: 0x00000053 c'est le numéro de sequence du fichier redo, en décimal c'est 83=5*16+3.

hws: 0x4 c'est header write seq#

nab: 0xffffffff le prochain bloc disponible (next available block)

flg: 0x8 c'est le type de fichier (ici un fichier redo en ligne). Le drapeau peut prendre les valeurs suivantes :

KCCLESPL 0x0001 /* si le fichier redo est spooled */
KCCLENAL 0x0002 /* set if No more ALlocation may be done in log */
KCCLEUSM 0X0004 /* si c'est le prochain fichier redo en ligne (USM : Use Me) */
KCCLECUR 0x0008 /* le fichier redo en ligne (CUR : current) */
KCCLECLR 0x0010 /* si le fichier redo vient d'être initialiser par la commande CLEAR(CLR : CleaR) */

Low scn: 0x0000.0031b9a8 10/23/2005 00:40:37 c'est le SCN quand le fichier redo à commuter en Next scn: 0xffff.ffffffff 01/01/1988 00:00:00 . next scn est soit égale à low scn du prochain fichier redo ou 0xffff.ffffffff s'il est encore en ligne.

Dans la section FILE HEADER on'a :

Compatibility Vsn = 169869568=0xa200100 veut dire une base en 10.2.01

Db ID=1483236283=0x586863bb

Control Seq=2084=0x824, c'est le numéro de séquence du fichier de contrôle, ce numéro est nécessaire pour trouver le bon fichier de contrôle suite à une restauration.

File Type=2 LOG c'est le type du fichier, le type 2 veut dire un fichier redo.

KCCTYPCF 1 /* control file */
KCCTYPRL 2 /* redo log file */
KCCTYPDF 3 /* vanilla db file */
KCCTYPBC 4 /* backup control file */
KCCTYPBP 5 /* backup piece */
KCCTYPTF 6 /* temporary db file */

descrip:"Thread 0001, Seq# 0000000083, SCN 0x00000031b9a8-0xffffffffffff"
C'est un texte en ASCII juste une aide pour le deboguage.

thread: 1 nab: 0xffffffff seq: 0x00000053 hws: 0x4 eot: 1 dis: 0

thread : le numéro de thread pour ce fichier redo
nab : prochain bloc disponible
seq : le numéro de sequence du fichier redo
eot : indique si c'est le dernier log (End Of Thread). Il prend les valeurs suivantes :

KCRFHENOT 0 /* NOT end of thread */
KCRFHEPUB 1 /* End of thread for PUBLIC thread */
KCRFHEPVT 2 /* End of thread for PRIVATE thread */

dis : DISabled - Vrai si le thread est désactivé à la fin de ce log.

F. Dump du fichier redo en entier

A partir de SQL on peut lancer la commande suivante :

ALTER SYSTEM DUMP LOGFILE 'filename';

Il faut entrer le nom complet du fichier redo entre les simples quotes.

Par exemple:

 ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V7323/dbs/arch1_76.dbf';

IX. Les fichiers redo et les sauvegardes

X. Appendice

IX.1. RBA

Les entrées recentes dans le redo thread d'une instance oracle ont une adresse appelé RBA (Redo Byte Address) qui est constitué de trois parties :

Le numéro de séquence du fichier journal (4 bits)
Le numéro du bloc du fichier journal (4 bits)
Offset du bloc dans lequel le redo record commence(2 bits)

Les RBA ne sont pas nécessairement unique dans leurs thread, puisque le numéro de sequence du fichier journal peut être mis à 1 dans tous les thread si la base est ouverte avec l'option RESETLOGS.

Les RBA sont utilisés dans les cas suivants :

En ce qui concerne les blocs modifiés dans le buffer cache, le low RBA est l'adresse redo de la première modification qui a été appliqué au bloc depuis le dernier nettoyage. Le High RBA est l'adresse redo de la plus recente modification appliqué au bloc.

Les tampons modifiés sont conservés dans la file d'attente checkpoint du buffer cache dans l'ordre du low RBA. Le checkpoint RBA est le point à partir duquel DBWn à écrit des tampons depuis la file d'attente checkpoint si le checkpointing incremental à été activé - autrement il est le RBA du dernier checkpoint du thread complet. Le checkpoint RBA est copié dans le record checkpoint progress du fichier de contrôle par le checkpoint heartbeat une fois chaque 3 secondes. La restauration de l'instance, quand c'est nécessaire, commence depuis le checkpoint RBA enregistré dans le fichier de contrôle. Le target RBA est le point à partir duquel DBWn devrait chercher pour avancer le checkpoint RBA pour satisfaire les objectices de la restauration de l'instance.

Le on-disk RBA est le point à partir duquel LGWR à vider le redo thread dans les log files en ligne. DBWn ne doit pas écrire un bloc dans lequel le high RBA est au-dela du on-disk RBA. Autrement la restauration de la transaction (rollback) ne pourrais pas être possible, car le redo nécessaire pour annuler la modification est toujours dans le même redo record comme le redo de la modification elle-même.

Le terme sync RBA est parfois utilisé pour indiquer le point à partir duquel LGWR est requis pour synchroniser le thread. Pourtant, ce n'est pas un RBA complet - seulement le numéro du bloc redo est utilisé à ce point.

Le low et high RBA pour les tampons modifiés peuvent être vue dans X$BH. (Il y'a aussi un RBA de restauration qui est utilisé pour enregistrer une restauration d'un bloc en cours ou partiel par PMON). Le incremental checkpoint RBA, le target RBA et le on-disk RBA peuvent aussi être vues dans X$KCCCP. Le checkpoint RBA d'un thread complet paut être vue dans X$KCCRT.

IX.2. RDBA et DBA

Chaque bloc oracle est identifié par un numéro unique qui est la combinaison d'un numéro de fichier et d'un numéro de bloc. Cette combinaison est representée par RDBA (Relative Data Block Address).

Pour connaître le RDBA du bloc 7 contenu dans le fichier 5

SQL> select dbms_utility.make_data_block_address( 5, 7) from dual;

20971527

Pour trouver la valeur en hexadecimal de 20971527 :

SQL> select to_char(dbms_utility.make_data_block_address( 5, 7),'xxxxxxxx') from dual;

1400007

Donc, 1400007 est le RDBA du bloc de données 7 qui se trouve dans le fichier 5.

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.