Réglages des redo

Date de publication : le 20 Octobre 2005

I. log file switch completion
II. log file switch (checkpoint incomplete)
III. L'attente de l'évènement log file sync
III.1. fréquence très élevée des validations
III.2. E/S lent
III.3. Log Buffer trop grand
IV. log file parallel write
V. log buffer space
VI. Log file sequential read
VI. Les latchs et les redos
VI-A. Le latch redo allocation
VI-B. Le latch redo copy
VI-C. Le latch redo writing

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

Un simple log switch entraîne l'arrêt des générations redo, lecture et écriture dans les fichiers de contrôle (statut et SCN des fichiers redo), décharge de la mémoire, fermeture et ouverture des fichiers redo et encore d'autres ressources.

Quelle est la taille du fichier redo ?

La réponse dépend de la taille du fichier redo en cours, du taux actuel de switch log et de 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 étapes d'un log switch :

La génération des redo est entièrement désactivés pendant un log switch. Cela ça se fait en fixant la variable SGA reflétant la cause et le statut du log switch. Les sessions à propos de l'allocation d'espace dans le log buffer vérifie cette variable en premier et si le log switch est en progression, il attend dans l'un des plusieurs évènements d'attentes associées avec le log switch. Aucune allocation d'espace dans le log buffer n'est tenté tant que le log switch n'a pas été finis, en plus, l'événement d'attente log buffer space ne devrait pas être vu pendant le log switch. Pourtant, si un grand nombre de process attend un log switch d'être fini alors il peut être une explosion de génération redo par la suite cela à pour résultat un deuxième attente de log buffer space.

Le process LGWR accompli les 4 étapes suivantes pour effectuer un log switch :

Il accompli une transaction de fichier de contrôle pour choisir le prochain fichier redo à utiliser et 'initialise l'entrée dans le fichier de contrôle. Normalement, c'est le fichier redo ayant le plus bas SCN qui est choisi. Si nécessaire, le log switch peut être retardé jusqu'au point où le process DBWR termine le log switch checkpoint suivant la précédente utilisation de ce fichier redo et jusqu'au processus ARCn à fini d'archiver. S'il en est ainsi , les sessions qui attendent le log switch devrait faire une pause dans l'événement d'attente log file switch (checkpoint incomplete) ou log file switch (archiving needed) à la place de l'événement log file switch completion.
Il décharge touts les redo restants du log buffer vers le disque, et écrit après le SCN du dernier enregistrement redo du fichier redo (le high SCN) dans l'entête du bloc du fichier redo. Une fois ces écritures sont finies, le process LGWR ferme le fichier redo.
Il fait avancer le SCN et accompli une deuxième transaction de fichier de contrôle pour marquer le prochain fichier redo comme CURRENT, et marque l'ancien fichier redo comme ACTIVE. Le statut de ce fichier redo devrait être modifié en INACTIVE, une fois le process DBWn à terminer le log switch checkpoint. Si la base est en mode ARCHIVELOG, alors le process LGWR ajoute aussi le fichier redo précédent dans la liste liée d'archive à travers la section des entrées du fichier redo dans le fichier de contrôle (voir V$ARCHIVE) et si l'archivage automatique est activé, il envoi le process ARCn pour l'archiver. A partir d'Oracle 8.1, le process LGWR peut créer un nouveau process ARCn jusqu'à la valeur log_archive_max_processes, si les processus d'archivages sont encore occupés.
Finalement, le process LGWR ouvre tous les membres du nouveau groupe de fichiers redo et écrit le nouveau numéro de séquence et le low SCN dans l'entête du bloc. Après, il active les générations des redo à nouveau.

Les écritures dans les blocs de l'en-tête du fichier redo durant les opérations d'ouvertures et de fermetures sont des opérations log file single write. Les écritures dans l'entête du bloc sont des simples écritures ( plutôt que les écritures parallèles dans tous les membres du groupe) car une partie des informations de l'entête est le numéro de fichier ce qui est différent pour chaque membre.

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.

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

III. 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 à la fois les transactions et les blocs modifiés dans le log buffer, une méthode connu sous le nom de : physiological logging. Le processus LGWR est responsable de libérer 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 ; le reste est connu sous le nom d'écritures background. L'attente log file sync est toujours en rapport avec les é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 utilisateur 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 vide les entrées redo en cours, inclus le marqueur commit, dans les fichiers redo. Durant la synchronisation de ces fichiers redo, le processus LGWR attend en faveur d'une écriture synchrone pour terminer dans l'événement log file parallel write tandis que la session utilisateur 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 aura deux possibilités pour sortir. L'un, est quand le process foreground est posté par LGWR quand la synchronisation des fichiers redo est complète. L'autre, est quand l'attente à fait une pause ( typiquement en 1 seconde), à un tel point que le process foreground vérifie le SCN courant du fichier redo pour déterminer si ces validations ont était effectué dans le disque. Si c'est arrivé, le process continue le traitement, sinon le process attend.

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.

III.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 de 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 développeurs d'applications ont appris que s'ils valident rarement, les jobs devrait s'échouer suite au manque d'espace dans les segments d'annulations. La bonne chose à faire est de valider à la fin de chacune des transactions. Une transaction est une unité de travail. Une unité de travail devrait réussir ou échouer dans son entité. La place convenable pour une validation ou annulation est à la fin de chaque unité de travail. Ne pas ajouter des validations supplémentaires aux bénéfices des espaces d'annulations ou des deadlocks. Il traite le symptôme mais ne résout pas le problème. (Si vous utilisez AUM, alors allouer plus d'espace au tablespace undo et mettre le temps de rétention undo approprié.)

Introduire des validations supplémentaires peut créer d'autres problèmes, parmi eux, la fameuse ORA-01555: l'erreur snapshot too old car l'annulation (ou undo) des données peuvent être sur écrites. Une fréquence de commit trop élevé 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 segment d'annulation (appelé segment d'annulation imposé) et mets à jours la table de transaction dans l'entête du segment d'annulation. La table de transaction doit être aussi mise à jours à la fin de chaque transaction, suivi par une validation de l'activité de nettoyage. Mettre à jours l'entête du segment 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 résoudra 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.

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

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

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

V. log buffer space

Dans 10g l'évènement log buffer space fait partie des classes des attentes Configuration. Il faut prendre en compte les considérations suivantes :

Les sessions attends dans l'événement log buffer space n'arrivent plus à copier les entrées redo dans le log buffer suite à un manque d'espaces.
Le process LGWR à la responsabilité de copier les entrées redo et de laisser la place à une nouvelle entrée.

En plus des statistiques de l'événement d'attente log buffer space, Oracle conserve aussi des statistiques redo buffer allocation retries au niveau session et système respectivement dans les vues V$SESSTAT et V$SYSSTAT. Les statistiques redo buffer allocation retries contient le nombre de fois que le process à attendu d'avoir de l'espace dans le log buffer. Pourtant, l'événement d'attente log buffer space c'est un très bon indicateur, car il contient les statistiques TIME_WAITED. Si une session passe beaucoup de temps dans l'événement d'attente log buffer space, c'est à cause des raisons suivantes :

Le log buffer dans le SGA est trop petit.
Le process LGWR est trop lent.

Un log buffer assez petit (moins que 512K) dans une base où il y'a des traitements batch, oblige les sessions à utiliser plus d'espaces dans le log buffer. Ajuster la valeur du LOG_BUFFER si c'est nécessaire. Le log buffer, n'est pas un composant dynamique du SGA, il faut redémarrer la base pour que le changement prenne effet.

Lorsque le débit d'E/S est assez lent, le process LGWR ne suivra pas la génération des redo et causera des attentes dans l'événement log buffer space. Les nouvelles entrées ne pourront plus écrire dans les entrées qui ne sont pas encore transférés dans le disque. Il faut s'assurer que la moyenne du temps d'attente dans l'événement log file parallel write est acceptable. Sinon, vous pouvez améliorer le débit d'E/S en utilisant la méthode utilisée dans la section log file sync.

On pourrait aussi voir comment l'application a été conçue pour réduire les activités des journaux. Utilisez les opérations NOLOGGING quand c'est nécessaire, il faut tenir compte que les objets créés par NOLOGGING ne peuvent pas être restaurés à moins qu'une sauvegarde ait été faite sur-le-champ. Si vous avez l'intention d'utiliser les opérations NOLOGGING, vérifier si l'option FORCE LOGGING est activée. L'option FORCE LOGGING peut être activé sur un objet, un tablespace ou sur la base. De même, vous pouvez checher les requêtes qui rapportent et mettent à jours une ligne en entier quand seulement quelques colonnes ont été modifiées. Ce n'est pas facile. Vous pouvez trouver ce comportement en fouillant les DML dans la vue V$SQL ou utiliser le logminer.

VI. Log file sequential read

VI. Les latchs et les redos

Les latchs qui protègent le log buffer sont :

Redo allocation
Redo copy
Redo writing

VI-A. Le latch redo allocation

Ce latch contrôle l'attribution d'espaces aux entrées redo dans le redo log buffer. Il y'a un seul latch redo allocation pour renforcer la nature séquentielle des entrées dans le buffer. Seulement après l'allocation, le process utilisateur doit copier l'entrée dans le buffer. Le process doit copier seulement en fonction du latch redo allocation si l'entrée redo est plus petit que le seuil de la taille, sinon un latch redo copy est nécessaire.

VI-B. Le latch redo copy

Un système avec plusieurs CPU doit avoir plusieurs latchs redo copy pour le redo log buffer. Dans un système à un seul CPU ne devrait pas avoir de contention pour le latch redo copy car seulement un seul process peut être activé au même moment.

VI-C. Le latch redo writing

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.