Réglages des redo
Date de publication : le 20 Octobre 2005
Par
Mohammed Bouayoun
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.
|
