FORUMS

TUTORIELS
FAQ
BLOGS
CHAT
NEWSLETTER
EMPLOI
ÉTUDES
DROIT
CLUB

DI/DSI Solutions d'entreprise Cloud IA ALM Microsoft Java Dév. Web EDI Programmation SGBD Office Mobiles Systèmes

SGBD 4D Access Big Data Data Science DB2 Firebird InterBase MySQL NoSQL PostgreSQL Oracle Sybase SQL-Server MongoDB

ACCUEIL ORACLE FORUM ORACLE F.A.Q ORACLE TUTORIELS ORACLE TUTORIELS SQL SCRIPTS SQL LIVRES ORACLE QUIZ

Les Fichiers redo

Date de publication : le 20 Octobre 2005

Par
Mohammed Bouayoun

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;

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

idea 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');

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

idea 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

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

warning 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

Et

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

LOG_ARCHIVE_DEST_1
LOG_ARCHIVE_DEST_n avec n entre 1 et ='LOCATION=/disk1/arc'
1 remote et local
10 LOG_ARCHIVE_DEST_2 =
'SERVICE=standby1'
LOG_ARCHIVE_DEST = '/disk1/arc'
LOG_ARCHIVE_DEST et
2 seulement local LOG_ARCHIVE_DUPLEX_DEST =
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.

idea 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

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

warning 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.
Piste la statu de l'archivage pour chaque destination du fichier redo
2
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.
Piste les modifications du paramètre de destinations des fichiers
32
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.
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 :

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 :

idea 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).

info 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 :

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

warning 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

info 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

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

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

info 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 :

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

2. Dump basé sur le RBA (Redo Block Address)
3. Dump basé sur le temp
4. Dump basé sur la couche et l'opcode
5. Dump de l'entête du fichier redo
6. 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;

info 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';

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

Oracle prévoit un bénéfice et un chiffre

Les nouveaux services d'IA cloud
d'affaires pour le trimestre en cours Java 17 : Oracle JDK est désormais
d'Oracle visent à apporter un Apprendre comment interroger une
supérieurs aux estimations, soutenus disponible gratuitement, y compris
apprentissage automatique prêt à base MariaDB depuis Oracle, un billet
par l'augmentation des dépenses en toutes les mises à jour de sécurité
l'emploi, pour les développeurs même blog de CinePhil
technologie pour favoriser le travail trimestrielles
sans expertise en science des données
hybride
Contacter le responsable de la rubrique Oracle

Nous contacter Participez Hébergement Publicité / Advertising Informations légales Partenaire : Hébergement Web
© 2000-2021 - www.developpez.com