Mthodologie de Tuning

lundi 29 juin 2009

par Laurent
Quand faire du tuning ?
Gnralement on se propose de raliser un peu de tuning lorsque les utilisateurs se plaignent
de temps de rponse dgrads. Le but du DBA est toujours de savoir interprter les plaintes
des utilisateurs finaux qui, gnralement, nauront quune phrase la bouche "mon
application est lente" !
Il faudra donc poser les bonnes questions, et identifier au mieux la cause des problmes.
Les bonnes questions devront porter sur :
Quand ? Dgradation ponctuelles, ou gnralises.
Depuis quand : y a-t-il une corrlation entre le problme constat et un changement
opr sur le systme (mise en production, changement de paramtrage,
dordonnancement etc.).
Comment ? Quelle rgle/cas dutilisation est concern par le problme. Cette question
permettra didentifier le(s) fonction(s) utilise(s) lorigine des problmes.
Tout est histoire de temps
Le tuning dapplication est une histoire de temps. Lquation fondamentale lie aux
problmes de tuning est la suivante :
Temps de rponse = Temps de Service + Temps dattente
Au sens Oracle, le temps de service se rsume au temps CPU. Le temps dattente correspond
la somme des waits Events enregistrs.
Ces temps peuvent tre mesurs au niveau de la session et au niveau du systme complet.
Pour traiter un problme de performance en se basant sur cette quation fondamentale, il faut
utiliser certains outils (AWR, requtes SQL, etc.) afin de dterminer o le plus grand du
temps est consomm. Une fois identifi, on se doit de corriger le problme en jouant sur
diffrents leviers, et renouveler lopration. En rsum :
Identifier l o le plus grande partie du temps est consomme
Obtenir les dtails afin de savoir pourquoi le temps est consomm sur une opration
particulire
Dterminer des axes damlioration (paramtre, rcriture de code )
Implmentation des changements, mesure des gains de temps (ou de la rgression) et
retour au premier point.
Les tats dun processus de traitement
Un processus de traitement se dcline gnralement en une chane de communication entre
processus client, processus serveur, instance et base de donnes.
Chaque processus serveur peut tre dans 3 tats principaux :
Inactif : Dans ce cas, il attend un message, une opration effectuer, un signal de
reprise de traitement etc. Mais le processus ne travaille pas.
Actif : Un processus est actif lorsquil consomme du temps CPU pour la ralisation
dun traitement. Un processus est galement actif lorsquil a transmis une demande de
traitement au systme et que cette demande est dans les files de traitement CPU (Run
Queue). Oracle na aucun moyen de savoir si le systme nest pas satur dans ces
chanes de traitement.
En attente : le processus est actif mais est en attente de la libration dune ressource
(verrou, latch) ou il attend la fin dune opration de lecture/criture de donnes, ou
encore la fin dun checkpoint par exemple.
Configurer linstance pour le tuning
Veiller ce que le paramtre STATISTICS_LEVEL soit TYPICAL ou ALL. (Pour les
versions <10g, veiller ce que le paramtre TIMED_STATISTICS soit TRUE).
Pour les configurations en 10g et suprieures, et si on dsire analyser les historiques, veiller
ce quil y ait assez de donnes conserves dans le rfrentiel AWR.
O regarder ?
Le premier point regarder est le temps consomm par notre systme Oracle sur du temps
CPU. Le temps CPU est mesur par une statistique systme "CPU Used by this session".
Cette statistique compte le temps CPU pass du dbut dune opration sa fin. Elle inclut
donc le temps de parse (Analyse SQL) pass par chaque appel (Cette information particulire
est dfinie par la statistique "parse time CPU"). On pourra mettre en rapport ces deux
statistiques pour mesurer si le problme du temps CPU provient du parse ou de lexecute par
exemple.
Plus dinfo sur ces statistiques dans la documentation de reference Oracle :
http://download.oracle.com/docs/cd/...
Les informations sur ces statistiques sont disponibles dans les vues suivantes :
V$SYSSTAT pour les informations en temps rel agrges pour toute linstance
(SYStme)
V$SESSTAT pour les informations en temps rel agrges par session
DBA_HIST_SYSSTAT pour les informations historiques (en 10g et sup.)
En revanche, quand Oracle attend quelque chose, il logue un vnement dattente (ou wait
event). Ces vnements sont classs. En 10g, oracle a introduit OWI (Oracle Wait Interface)
permettant de mieux classifier ces events. Parmi ces diffrentes classes, on trouve la classe
"Idle". Les Idle events sont des vnements indiquant que le processus est en attente de
travail.
Les autres events indiquent une attente active sur une ressource occupe (I/O user, I/O
systme, verrous etc.)
Le dtail des vnements dattente est disponible dans la documentation de rfrence :
http://download.oracle.com/docs/cd/...
On trouve galement ces informations dans les vues suivantes :
V$EVENT_NAME pour le dtail des events et leur classification
V$SYSTEM_EVENT pour savoir sur quels events le systme a attendu
V$SESSION_EVENT met disposition tous les vnements dattentes enregistrs par
session
V$SESSION_WAIT indique en temps rel sur quel vnement attend la session. Dans
cette vue, on obtient galement les paramtres de chaque vnement. Les paramtres
(P1,P2, et P3) permettent dobtenir plus dinformations sur la ressource concerne par
lattente (Bloc, objet, type de verrous, information de latch etc.)
Les informations pertinentes concernant lobservation des temps peuvent tre rsumes
comme suit :
Ignorer les vnements classs comme "Idle". Ces vnements sont enregistrs mais
ne dmontrent pas que la base attend activement sur une ressource. Les plus connus
sont les suivants :
o SQL*Net Message from client : Cet event est enregistr car la session attend
une instruction.
o ASM Background Timer : le process ASMB attend une instruction
o SMON Timer : le SMON attend une instruction
Ignorer les vnements dattentes reprsentant une faible partie du temps total des
attentes.
Classifier et comparer les proportions des temps par vnement par rapport au temps
total des attentes
Le simple fait danalyser les temps dattente ne suffit pas !!!! Il faut donc veiller
comparer le temps total des attentes actives par rapport au temps CPU.
Enfin, attention aux units de temps. Gnralement, oracle travaille au centime de seconde,
mais une vrification systmatique des temps simpose.
Le pige de lanalyse systmatique des temps dattentes
Plus haut, jai prcis que lanalyse des temps dattente ne suffisait pas.
Lquation de base est :
Temps de rponse = Temps de Service + Temps dattente.
Il va de soi que si on se trouve dans le cas suivant :
Temps de rponse = 10 secondes
Temps de service = 9 secondes
Temps dattente = 1 seconde dtaille comme suit :
o 950 ms dattente sur "db file scattered read"
o 25 ms dattente sur "log file sync"
o 25 ms dattente sur "control file parallel write"
Et quon se focalise faire diminuer les 95% de db file scattered read (par rapport la totalit
des attentes actives), on se dtourne du problme, savoir les 90% du temps de rponse pass
sur le CPU (Temps de service).
Il faut donc toujours veiller travailler sur "le temps de rponse" et pas systmatiquement sur
"les temps dattente"
Jattire votre attention sur la diffrence fondamentale entre un rapport Statpack (<9iR2) et
statspack (>=9ir2), AWR (10g et sup) sur une partie du rapport qui intresse nombre de
DBA : le TOP 5 des events.
En statspack (<9ir2), ce "TOP 5" est un "Top 5 Wait Event". Alors que dans dautres versions
et en AWR, on a un "Top 5 Timed Event". Dans ce dernier, le temps CPU est intgr.
Lorsquon aura un "Top 5 Wait Event", on se devra donc daller chercher linformation de la
statistique CPU Used by this session" disponible plus bas dans le rapport (partie "Instance
Activity Stats").
Exemple :

Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait %
Total
Event Waits Time (cs) Wt
Time
-------------------------------------------- ------------ ------------ ----
---
db file sequential read 429,613 302,076
64.78
direct path read 121,753 109,465
23.47
db file scattered read 41,853 23,726
5.09
direct path write 54,079 17,552
3.76
latch free 10,706 7,703
1.65

/

Statistic Total per Second per
Trans
--------------------------------- ---------------- ------------ -----------
-
CPU used by this session 888,828 980.5
155.5
Dans ce cas, on a :
o Temps dattentes : 302076 * 100 / 64,78 soit 466 310 centime de seconde =
4663 sec.
o Temps de service : 888828 centime de seconde = 8888 sec.
o Temps de rponse : 8888 + 4663 = 13551 sec.
On a donc : CPU Used by this session = 65,6 % du temps de rponse Attentes : 34,4%
rparties comme suit :
Db file sequential read : 22,3% du temps de rponse
Direct Path read : 8% du temps de rponse
Db file scattered read : 1,74% du temps de rponse
Direct path write : 1,3% du temps de rponse Aprs cela, on traitera en premier lieu
les temps de rponse CPU. Puis ensuite, la cause des 22% de "db file sequential read".
Rappel : Si on dispose de la vue "Top 5 Timed Event", le temps CPU est pris en compte
dans ce classement.
Aprs lidentification, laction
Si ca se passe sur les CPUs
Dans un premier temps, il faut sassurer que, ct systme, les files de traitements (run-queue
size) ne sont pas satures. Si cest le cas, le problme vient peut-tre dailleurs. Pour raliser
cela, des outils systme comme vmstat, sar permettent dobtenir cette information.
On se doit didentifier quelle opration est coteuse.
Les oprations coteuses en CPU sont de plusieurs ordres au niveau Oracle.
Soit le problme est un problme de parse. Lanalyse des ordres SQL (Parse) est une
opration coteuse en temps CPU. Cette information sobtient en observant deux
statistiques :
o CPU User by this session
o Parse time cpu Etablir le ratio parse/temps CPU permet de savoir, si le temps
CPU consomm lest essentiellement sur de lanalyse.
Si cest le cas, on orientera notre recherche sur :
o Recherche dordre SQL utilisant des littraux (et non des bind variables)
o Taille du shared pool
o Mauvaise utilisation des curseurs
o Analyse et r-criture des textes SQL
Soit lanalyse des excutions permet dtablir des consommateurs CPU. Les ordres
SQL peuvent tre extrmement consommateurs en temps CPU (hors parse) lorsquun
plan est mauvais par exemple. Lidentification des sessions consommant une charge
importante en CPU peut tre obtenue avec la requte suivante :

col program for a30
col machine for a10
col username for a10
set lines 350
set pages 350

SELECT v.sid, substr(s.name,1,30) "Statistic", v.value "Statistic
value",
sess.program, sess.machine,sess.username,sess.logon_time
FROM v$statname s , v$sesstat v, v$session sess
WHERE s.name = 'CPU used by this session'
and v.statistic#=s.statistic#
and v.sid=sess.sid
and v.value>0
ORDER BY 3
/
Une fois la session identifie, on peut alors mettre celle-ci en trace, analyser les plans
dexcution des requtes (via sql_trace & tkprof) et dterminer le point posant problme
(Produit cartsien, volume de donnes important etc.).
Dans les donnes historiques (statpack, AWR), on peut retrouver des pistes sur des sessions
consommatrices en temps CPU. Notamment, sur celles qui vont consommer de nombreux
buffer (Partie de rapport : "SQL ordered by Gets").
A partir doracle 10g et des rapports AWR, une rubrique "SQL ordered by CPU Time" fait
son apparition, celle-ci permet davoir une classification des consommations en temps CPU
par ordre SQL. Cela dit, ce temps inclut les temps de parsing, il faut donc prendre ces
informations avec objectivit et sassurer que le temps de parse nest pas le problme pour
cette instruction.
Si ca se passe cot vnements dattentes
Si le problme est constat du cot des vnements dattentes, il faut alors qualifier le
problme et dterminer les axes damlioration, dun point de vue gnral (porte de
linstance) tout en sachant identifier les sessions problmatiques.
Dans cette partie, je vais dtailler quelques vnements dattentes couramment observs ainsi
que leur cause. Pour plus dinformations, sur les vnements dattente, consulter la
documentation suivante : http://download.oracle.com/docs/cd/...
Db file sequential read
Cet vnement est enregistr lorsquOracle attend quune Entre/sortie de lecture se termine.
Cet vnement se produit gnralement lors de la lecture dun bloc.
Attention, la lecture de cet vnement. En effet, les lectures sont tout fait normales au
niveau dune base de donnes. Il faut juste veiller que leur nombre ne se dgrade pas, et que
ces lectures soient efficaces.
Pour limiter limpact de ces I/Os, on peut vrifier :
A avoir des disques suffisamment performants
A avoir un cache de tampon suffisant. Pour cela, il faut observer les courbes de
conseils obtenus avec la vue V$DB_CACHE_ADVICE avant toute augmentation.
A avoir un facteur de clusterisation dindexes optimal (ie. proche du nombre de blocs
de la table indexe et loign du nombre de lignes indexes)
A avoir et utiliser les bons objets (IOT, Indexes Uniques, Bitmap indexs, tables et
indexes partitionns etc.) afin de limiter les oprations dI/Os
La vue V$FILESTAT permet dobtenir des informations sur la rpartition des I/Os. De plus,
lors dune analyse en temps rel, la vue V$SESSION_WAIT permettra dobtenir les
paramtres de lvnement. Or pour cet vnement, le P1 correspond lidentifiant du fichier,
le P2 au bloc concern.
Avec la requte suivante, on pourra donc obtenir les informations ncessaires pour identifier
lobjet :

SELECT owner , segment_name , segment_type
FROM dba_extents
WHERE file_id = <FILE_ID>
AND <BLOCK_ID> BETWEEN block_id AND block_id + blocks -1 ;
La vue V$SEGMENT_STATISTICS permet davoir les informations de lecture/criture par
segment.
db file scattered read
Cet vnement est enregistr lors de lecture multi-blocs. Ces lectures interviennent lors de
Full Scan de Table ou dindex.
Une opration va lire un certain nombre de blocs. Ce nombre est dtermin par le paramtre
DB_FILE_MULTIBLOCK_READ_COUNT.
Si le temps consomm sur cet vnement est important, il faut alors identifier les segments
posant problme. Pour cela, on peut utiliser la vue V$SEGMENT_STATISTICS ou encore
les paramtres P1 et P2 de lvnement qui correspondent respectivement lidentifiant du
fichier et lidentifiant du premier bloc concern.
Une diminution de ces temps se ralise gnralement en optimisant les accs au bloc. Cet
effet peut sobtenir en diminuant les Full Scan (Table / index).
Quelquefois, le paramtre DB_FILE_MULTIBLOCK_READ_COUNT est paramtr une
valeur trop leve. Ceci a pour consquence de favoriser (par loptimiseur) les lectures
multiples de blocs, et donc de faire augmenter le nombre et le temps consomm sur ces
vnements.
Des statistiques obsoltes peuvent galement drgler certains plans dexcution en favorisant
les lectures multiples.
Buffer Busy Waits
Le "Buffer Busy Waits" (BBW) est enregistr lorsquune session cherche accder un bloc
de donnes en mmoire et que ce bloc est "Occup" (Busy en anglais).
Il est occup car une session est en train de le lire ou de le modifier.
L encore, si le temps occup par cet vnement est important. On doit identifier les objets
concerns par cet vnement, mais aussi le type de bloc (data, undo, header etc.) concern
afin de raliser les corrections optimales.
Lidentification des objets ayant enregistr le plus de BBW se fait avec linterrogation de la
vue V$SEGMENT_STATISTICS. Une fois lobjet identifi, la rpartition des BBW sur le
type de bloc se ralise avec la requte suivante :

SELECT time, count, class
FROM V$WAITSTAT
ORDER BY time,count;
2 3
TIME COUNT CLASS
---------- ---------- ------------------
0 0 sort block
0 0 undo block
0 0 save undo block
0 0 segment header
0 0 save undo header
0 0 free list
0 0 extent map
0 0 1st level bmb
0 0 2nd level bmb
0 0 3rd level bmb
0 0 bitmap block
0 0 bitmap index block
0 0 file header block
0 0 unused
0 0 system undo header
0 0 system undo block
0 0 undo header
50 11 data block

18 ligne(s) selectionnee(s).
Une analyse en temps rel permet galement didentifier le bloc concern. La requte utilise
sera la suivante :

SELECT sid, p1, p2, p3
FROM v$session_wait
WHERE event='buffer busy waits';
Une fois le bloc identifi, on peut dterminer lobjet concern avec la requte suivante :

SELECT owner , segment_name , segment_type
FROM dba_extents
WHERE file_id = <FILE_ID>
AND <BLOCK_ID> BETWEEN block_id AND block_id + blocks -1 ;
Laction corrective va dpendre du type de bloc.
Si cest un bloc de donnes (majorit des cas), il faut faire en sorte de diminuer le
nombre de lignes par bloc. Pour cela, on peut user de diffrents stratagmes :
o Diminuer la limite de remplissage du bloc (PCTFREE). Mais cela augmente le
nombre de blocs par objet et donc le nombre de lectures se ralisant par
RANGE SCAN ou en FULL SCAN.
o Dans le cadre de la lecture dindex par RANGE SCAN, si une plage de valeurs
indexes est souvent accde, cela peut poser des problmes. On peut donc
utiliser des indexes inverss (Ou REVERSE INDEX) pour rpartir
diffremment les accs.
o On peut aussi augmenter lINITTRANS pour limiter la taille de la partie de
donnes du bloc
Si cest un bloc dentte de segment, gnralement il ny a pas assez de FREELIST et
la contention sur cette FREELIST se fait ressentir par un BBW. Pour cela, soit il faut
passer en gestion automatique des segments (ASSM) soit augmenter le nombre de
Freelist.
Si cela se produit alors que lobjet est dans un tablespace ASSM (Rare). Alors, il faut
positionner lobjet dans un tablespace gr manuellement avec un nombre de FREELIST
correct pour cet objet.
Si cest un bloc dundo, et que lon est en gestion manuelle des annulations, alors les
rollback segments sont trop petits, il faut donc augmenter le nombre dextents de ces
RBS.
Si cest un bloc dentte dundo, et que lon est en gestion manuelle des annulations,
alors il faut augmenter le nombre de rollback segments.
Free Buffer Wait
Cet vnement est enregistr lorsquune session cherche obtenir une page du buffer libre et
quelle nen trouve pas.
Ce cas peut se raliser lors de la monte dun bloc disque dans le cache de tampon.
Lorsque le temps consomm sur cet vnement est important, cela dnote que le processus
dcriture DBWn nest pas assez performant pour crire, et donc librer, les blocs modifis et
identifis comme "dirty" dans le cache de tampon.
Les taux dcriture sont donc mauvais, et il faut pallier cette lacune par diffrentes actions :
Diminuer la charge dcriture sur les disques en rpartissant au mieux les fichiers de
donnes
Utiliser ASM (qui travaille en RAW)
Utiliser les I/Os asynchrones si le systme dexploitation le supporte, sinon utiliser le
paramtre DBWR_IO_SLAVES pour simuler un tel fonctionnement.
Augmenter le nombre de processus DBWn en augmentant le paramtre
DB_WRITER_PROCESSES. Cependant, il faut faire attention une telle
modification, notamment au niveau de la charge systme et au niveau de la rpartition
des fichiers sur les disques.
Enqueue
Les vnements denqueue sont enregistrs lors quune session tente daccder ou de modifier
une ressource protge par un verrou logique quon appelle enqueue. Les enqueues sont
classs par type en fonction de ce quils protgent et comment ils protgent lobjet.
Si le temps dattente sur cet vnement est important, on se doit donc didentifier sur quel
type denqueue. En Oracle 10g, les vnements dattente denqueue sont qualifis dans
lvnement. Ils prendront la forme
"Enq : typage et description de lenqueue"
En oracle 9 et infrieurs, il faudra dterminer quel type denqueue cause la majorit des
attentes. Pour cela (la mthode fonctionne galement en 10g), on pourra lancer la requte
suivante :

SELECT eq_type Enqueue_type,total_req# requests,
total_wait# Waits,cum_wait_time cumul_wait_time
FROM V$enqueue_stat
WHERE Total_wait# > 0;

EN REQUESTS WAITS CUMUL_WAIT_TIME
-- ---------- ---------- ---------------
CF 3935 4 2600
JS 75376 4 1750
PR 17 1 70
Les statistiques sont archives dans AWR et sont accessibles via la vue
DBA_HIST_ENQUEUE_STAT.
Lidentification des sessions ralisant ces enqueues (via la vue V$SESSTAT) et des sessions
bloques/bloquantes (via les vues DBA_WAITERS, DBA_BLOCKERS, V$LOCK,
V$LOCKED_OBJECTS) permettra didentifier les objets verrouills et dagir en fonction de
lenqueue.
Les principaux enqueues rencontrs sont les suivants :
TX : Cet enqueue est pos sur une ligne lorsque celle-ci est modifie afin de la
protger contre dautres oprations dcriture simultanes. Les problmes denqueues
gnrs se rsolvent par un changement de la logique applicative ou de la structure des
tables (Foreign Key non indexes etc.)
TM : Cet enqueue est pos afin dempcher la modification de structure de table
lorsque ses donnes sont modifies. On lappelle galement "DML Enqueue". Les
problmes denqueue de ce type sont gnralement rsolus par un changement de la
logique applicative.
CF : Cet enqueue est positionn lorsque les fichiers de contrles sont accds. Si les
disques sur lesquels sont positionns les fichiers de contrle ne sont pas assez rapides,
alors on verra les statistiques de cet enqueue (V$ENQUEUE_STAT) augmenter.
/
Latch Free
Un latch est un mcanisme de verrouillage bas niveau visant protger les accs concurrents
la mmoire partage. Ces latch fonctionnent de deux manires :
En "No Wait" : Dans ce mode, si le latch nest pas disponible, alors un nouveau latch
est allou. Si la demande naboutit pas, elle nest pas ritre.
En "Willing to wait" (mode de fonctionnement dominant) : dans ce mode, si le latch
nest pas disponible alors le systme ritrera la demande tant que le latch ne sera pas
obtenu. Le temps dattente est conditionn par un paramtre cach (_SPIN_COUNT).
La modification de ce paramtre nest recommande que sur avis du support
(paramtre non document).
Lorsque lvnement "latch free" est enregistr, cela signifie que la demande de latch na pu
aboutir. Comme les enqueues, les latch sont classs et lincapacit obtenir des latchs dun
type particulier peut engendrer des problmes de performances.
Identification
Dans un premier temps, il faut identifier la classe de latch qui pose le plus de problmes.
Celle-ci sobtient avec la requte suivante :

SELECT latch#, name, gets, misses, sleeps
FROM v$latch
WHERE sleeps>0 ORDER BY sleeps;

LATCH# NAME GETS MISSES SLEEPS
---------- -------------------- ---------- ---------- ----------
42 slave class create 34 2 2
214 shared pool 100798 2 3
148 redo allocation 14455 3 3
La classe posant problme est celle ayant le plus de SLEEPS. Cependant, il peut y avoir
plusieurs latchs dans une mme classe. Pour avoir ce dtail, on doit interroger la vue
V$LATCH_CHILDREN pour obtenir lidentifiant du latch qui pose souci :

SELECT addr, latch#, gets, misses, sleeps
FROM v$latch_children
WHERE sleeps>0
and latch# = 148
ORDER BY sleeps ;
ADDR LATCH# GETS MISSES SLEEPS
-------- ---------- ---------- ---------- ----------
3D6852F0 148 5947 3 3
Si, ce niveau, la rpartition des SLEEPS est ingale, cela signifie que le(s) latch(s) dadresse
ADDR pose problme.
Correction des problmes
Pour la correction des problmes de latch free, tout dpend du type de latch.
Parmi les principaux :
Cache buffer chains : lorsque ce type de latch pose problme. Le latch est demand
pour protger les lments des listes daccs aux buffers. Pour ce type de problme, il
faut, en fonction de ladresse du Latch, identifier quel(s) bloc(s) et donc quels objets
sont cibls par ce latch.
Pour cela, on utilise la requte suivante :

select /*+ RULE */
e.owner ||'.'|| e.segment_name segment_name,
e.extent_id extent#,
x.dbablk - e.block_id + 1 block#,
x.tch,
l.child#
from
sys.v$latch_children l,
sys.x$bh x,
sys.dba_extents e
where
x.hladdr = '&ADDRESSE' and
e.file_id = x.file# and
x.hladdr = l.addr and
x.dbablk between e.block_id and e.block_id + e.blocks -1
order by x.tch desc ;
Les blocs des segments ayant le TCH le plus lev, ie. le nombre de hit daccs, peuvent alors
tre considrs comme des HOTBLOCK. Pour cela, plusieurs pistes :
o Diminuer le nombre de lignes par bloc en augmentant le PCT_FREE du
segment
o Augmenter le dbit des DBWn par augmentation du nombre de processus
DBWn
o Implmenter les REVERSE INDEX (dans le cas de range scans)
o Revoir le code SQL.
library cache / shared pool : lorsque les latchs de type "library cache" ou "shared
pool" posent problme, ils traduisent gnralement une mauvaise configuration de la
shared_pool. Mais le plus souvent, ils dnotent dune mauvaise utilisation du langage
SQL. Et encore plus prcisment, ils dnotent dune utilisation de valeurs littrales
aux dpens des variables attaches (Bind Variables).
Plus rarement, ils peuvent rsulter dune mauvaise gestion des curseurs (configuration du
cache de curseur (SESSION_CACHED_CURSORS), curseurs ferms aprs chaque excution
etc.), de frquents logon/logoff, ou encore dune shared pool area trop petite.
Cache buffers lru chain : lorsque ces latchs posent problme, ils dnotent une forte
activit sur les listes LRU du cache de tampon. Cette suractivit est gnralement due
de larges scans (RANGE ou FULL) dobjets en cache (indexs non slectifs, tables
volumineuses non partitionnes etc.).
Il existe galement dautres pistes comme une inefficacit des processus DBWn. Cette
inefficacit est elle-mme due des disques surchargs ou une mauvaise distribution des
fichiers de donnes sur les disques.
Control File Parallel Write
Cet vnement est enregistr lorsquun processus serveur met jour toutes les copies des
fichiers de contrle. Si ce temps dattente est consquent, il faut sassurer que le dbit des
disques, des contrleurs de disques sont suffisants (par une analyse systme via iostat).
Lorsque cet vnement est constat, on peut essayer plusieurs pistes :
Vrifier que le nombre de fichiers de contrle nest pas trop important.
Vrifier que la plateforme gre les I/Os asynchrones.
Sassurer que les fichiers de contrle ne sont pas situs sur des disques trop saturs.
Log Buffer Space
Cet vnement est remont lorsquun processus serveur tente dcrire linformation
transactionnelle dans le redo log buffer. La cause de cette attente peut tre due un redo log
buffer trop petit. Cet vnement est galement enregistr lorsque le LGWR na pas encore
crit toutes les informations de ce log buffer vers les fichiers de redo log en ligne.
Pour corriger ce problme, il faut :
Soit augmenter le redo log buffer si celui-ci est trop petit
Soit constater puis faire diminuer la charge en I/O sur les systmes de fichiers
hbergeant les redo log en ligne. Ceci afin daugmenter les performances du LGWR.
Log File Parallel Write
Cet vnement est remont par le processus LGWR lors de lcriture des donnes du buffer
dans le groupe de redo log courant contenant plusieurs membres.
Si des mcanismes dI/O asynchrones ne sont pas mis en place, ou si les membres dun
groupe de redo-log sont situs sur les mmes disques physiques, alors les donnes seront
crites squentiellement dans les fichiers. Le temps attendu sur lacquittement de ces critures
sera enregistr dans cet vnement.
Il faut donc faire diminuer les temps dcriture dans les membres des groupes de redo log en
ralisant diffrentes oprations :
Positionner ses membres de redo log sur des disques rapides (Disques SSD plutt que
disques mcaniques par exemple)
Ne pas favoriser le positionnement de ces fichiers sur des volumes en RAID 5 ou pire
RAID 6.
Faire en sorte davoir un nombre de membres par groupe qui scurise la plate-forme
sans tomber dans la paranoa et ainsi, multiplier le nombre de fichiers crire.
NB : Pour les personnes grant les sauvegardes chaud par script utilisateur, une
augmentation de cet vnement peut tre constate et ce, du fait du passage des
tablespace en mode BEGIN BACKUP. Ce mode stocke dans les redo-log, les images des
blocs modifis, linformation crire sera donc plus importante et donc plus lente.
Log File Sync
Cet vnement va tre enregistr lors de la synchronisation des redo log. Cette
synchronisation sopre lorsquun COMMIT (explicite ou implicite) ou un ROLLBACK
intervient sur linstance.
Lors de ces oprations, le contenu du redo log buffer est inscrit dans les redo log en ligne.
Le temps pass raliser les critures (log file parallel write event) est inclus dans le temps de
lvnement "log file sync".
Si le temps consomm par cet vnement est significatif, il peut y avoir deux causes cela :
Soit les temps de rponse des disques sur lesquels sont placs les redo log sont
mauvais, auquel cas, les temps dattentes sur lvnement "log file parallel write"
seront galement levs.
Soit le nombre de transactions par seconde est trop important, dans ce cas, les attentes
"log file parallel write" sont significativement moins importantes que les attentes de
type "log file sync".
En termes de corrections, selon le cas constat, il faudra :
Veiller ce que les redo log soient sur des disques rapides et que ces disques ne soient
pas surchargs par dautres charges dentre/sortie (fichiers de donnes par exemple).
On vitera, dans la mesure du possible, de positionner les redo log sur des volumes
RAID5 (ou pire RAID6) rputs pour leur moindre performance en criture.
Revoir le code pour faire diminuer le nombre de transactions par seconde.