Discussion :

[aline]

Bonjour à tous,

J'ai toujours des problèmes de library cache. voici un morceau de statspack:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
 
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read                            91,873       2,237    44.36
latch free                                         19,912       1,978    39.21
CPU time                                                          191     3.78
db file scattered read                              2,689         188     3.74
log file sync                                      10,947          98     1.94
 
 
^LLatch Sleep breakdown for DB: PROD  Instance: PROD  Snaps: 12577 -12578
-> ordered by misses desc
 
                                      Get                            Spin &
Latch Name                       Requests      Misses      Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
library cache                     679,090      11,839      10,365 2385/8648/71
                                                                  9/87/0
 
 
 
^LLatch Miss Sources for DB: PROD  Instance: PROD  Snaps: 12577 -12578
-> only latches with sleeps are shown
-> ordered by name, sleeps desc
 
                                                     NoWait              Waiter
Latch Name               Where                       Misses     Sleeps   Sleeps
------------------------ -------------------------- ------- ---------- --------
library cache            kglpndl: child: before pro       0      2,144    2,008
library cache            kglpndl: child: after proc       0      1,412       42
library cache            kglhdgn: child:                  0      1,381    2,284
library cache            kgldte: child 0                  0      1,176    1,924
library cache            kgllkdl: child: cleanup          0        874      512
library cache            kglupc: child                    0        774       34
library cache            kglpnp: child                    0        490    1,007
library cache            kglobpn: child:                  0        437    1,028
library cache            kglpin: child: heap proces       0        429      775
library cache            kglic                            0        381      130
library cache            kglhdgc: child:                  0        297      142
library cache            kglpnc: child                    0        201      117
library cache            kgldti: 2child                   0        103       62

Si je suis les notes de Bouyao, les attentes les plus importantes se font à la connection et à la déconnection (child before et chid after process).

kglpnp signifierai pin deallocation ?!


Il est à noter que pendant ces intenses moment de latch, faire se connecter directement sur le serveur et faire un vi d'un fichier est également très long.


une piste?

[orafrance]

la machine swap ?

[aline]

très peux

Est ce que cela pourrai venir que je n'ai pas beaucoup de latch library cache?


SELECT name, count(*)
FROM v$latch_children
group by name
order BY count(*) desc;


1 cache buffers chains 4096
2 SQL memory manager workarea list latch 67
3 global tx hash mapping 67
4 simulator hash latch 64
5 channel operations parent latch 55
6 checkpoint queue latch 32
7 name-service namespace bucket 32
8 row cache objects 23
9 cache buffers lru chain 16
10 simulator lru latch 16
11 message pool operations parent latch 15
12 commit callback allocation 11
13 transaction allocation 11
14 buffer pool 8
15 shared pool 7
16 parallel query alloc buffer 4
17 session switching 4
18 post/wait queue 4
19 redo copy 4
20 Token Manager 3
21 undo global data 3
22 library cache pin allocation 3
23 library cache pin 3
24 library cache 3
25 job workq parent latch 3
26 enqueue hash chains 2
27 latch wait list 2
28 longop free list parent 2
29 parallel query stats 2
30 session idle bit 2
31 ksfv messages 2
32 TLCR meta context 1
33 granule operation 1
34 session queue latch 1
35 sim partition latch 1
36 redo allocation 1
37 msg queue latch 1
38 done queue latch 1
39 channel handle pool latch 1
[/code]


Dans ce cas comment l'augmenter.

ou bien que le nombre de process autorisé soit proche du nombre utilsé (je garde20% d marge)[/b]

[bouyao]

Bonjour Aline,

Ta dernière requête semble correcte seulement celui du

cache buffers chains 4096

un peut grand.

[aline]

Bonjour Aline,

Ta dernière requête semble correcte seulement celui du

cache buffers chains 4096

un peut grand.

Bonjour Bouyao,

Le problème, c'est que je ne sait pas du tout comment parametrer les latches. Existe t'il un paramètre d'initialisation pour cela?
Et comment savoir si on en a trop ou pas assez (par exemple sur quel critère peut-on se baser pour dire que

cache buffers chains 4096

est trop grand)?

C'est vraiment penible de voir qu'Oracle ne communique pas plus sur ce sujet qui fait parti des plus intéressants

[Jaouad]

Bonjour ,
la valeur en soit n'apporte pas grand chose !

Il faut plus s'interresser au ratio misses par rapport a get.

Combien de fois lorsque j'ai demandé un latch je ne l'ai pas eu de suite.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT addr, latch#, gets, misses, sleeps, ROUND (((misses*100)/gets),6) AS ratio 
    FROM v$latch_children
   WHERE sleeps>0
     AND latch# = (SELECT latch# FROM v$latchname 
WHERE name ='cache buffers chains')
   ORDER BY sleeps DESC

Oracle conseille d'avoir un ratio inférieur à 1%

Jaouad

[ducho]

Bonjour,

je suis d' accord avec toi aline, moi aussi la plupart de mes wait events
sont des "cache buffer chain" .
je n' ai pas trouvé comment optimiser cela .
Personnellement, je pense qu' oracle ne communique pas beaucoup
car d' une part ce n' est pas simple, d' autres part ils vendent des
prestations de tuning ( et les cours) ....

cdlt

[Jaouad]

Oracle communique quand même un peu la dessus :
Il existe différentes solutions :

Tuning du code
Si index on peut utiliser un reverse Index
Si table on peut envisager une table partitioné
modifier _db_block_hash_buckets et
_db_block_hash_latches avec le support Oracle .

(...)

Cache Buffer Chain

Jaouad

[aline]

Bonjour Jaouad,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
SELECT addr, latch#, gets, misses, sleeps, ROUND (((misses*100)/gets),6) AS ratio
    FROM v$latch_children
   WHERE sleeps>0
     AND latch# = (SELECT latch# FROM v$latchname
WHERE name ='library cache')
   ORDER BY sleeps DESC
 
1	AACA8E98	157	51852132	108125	71270	0.208526
2	AACA8F60	157	132732545	140262	58146	0.105673
3	AACA9028	157	44388500	89949	52619	0.20264

comme tu vois, je n'ai pas de problème de ratio en moyenne.

Mais j'ai clairement des problème de library cache sur certains moment.
Tout ce que je vois, c'est que pendant ces pics, deux autres évenements se produisent; un taux elevé de dbfile sequential read ainsi que un taux très bas dans statspack sur Parse CPU to Parse Elapsd.

Est-ce lié à de pauvres perfs au niveau des I/O?

voici deux extraits de statspcacks pris ce matin montrant un peux ce type de problème:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.98       Redo NoWait %:    100.00
            Buffer  Hit   %:   98.85    In-memory Sort %:    100.00
            Library Hit   %:   98.88        Soft Parse %:     97.04
         Execute to Parse %:   94.63         Latch Hit %:     99.89
Parse CPU to Parse Elapsd %:    0.26     % Non-Parse CPU:     98.54
 
 Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   84.19   82.36
    % SQL with executions>1:   43.47   43.84
  % Memory for SQL w/exec>1:   47.01   46.91
 
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read                           114,040       4,260    45.10
latch free                                         31,840       4,126    43.69
CPU time                                                          252     2.67
db file scattered read                              2,579         158     1.67
SQL*Net message from dblink                       180,152         113     1.19
          -------------------------------------------------------------
 
 
 
Latch Name                       Requests      Misses      Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
library cache                     651,653      15,001      13,388 2878/10995/1
                                                                  011/117/0
 
library cache            kglpndl: child: before pro       0      2,854    2,555
library cache            kglpndl: child: after proc       0      2,155       54
library cache            kglhdgn: child:                  0      1,805    3,062
library cache            kgldte: child 0                  0      1,608    2,489
library cache            kgllkdl: child: cleanup          0      1,191      623

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
 
 
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:    100.00
            Buffer  Hit   %:   98.34    In-memory Sort %:    100.00
            Library Hit   %:   99.92        Soft Parse %:     99.13
         Execute to Parse %:   95.54         Latch Hit %:     99.92
Parse CPU to Parse Elapsd %:    0.80     % Non-Parse CPU:     98.25
 
 Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   84.99   86.41
    % SQL with executions>1:   43.96   46.63
  % Memory for SQL w/exec>1:   48.68   52.39
 
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read                           161,014       2,938    50.36
latch free                                         24,714       1,625    27.86
CPU time                                                          291     4.99
log file sync                                      18,134         256     4.38
db file scattered read                              3,795         177     3.04
          -------------------------------------------------------------
 
Latch Name                       Requests      Misses      Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
library cache                   2,814,639      20,519      13,554 7919/11746/7
                                                                  72/82/0
 
library cache            kglpndl: child: before pro       0      3,147    3,189
library cache            kglpndl: child: after proc       0      2,285       57
library cache            kglhdgn: child:                  0      2,149    2,988
library cache            kglupc: child                    0      1,272       32
library cache            kglpnp: child                    0      1,065    2,702
library cache            kgllkdl: child: cleanup          0        789      310
library cache            kgldte: child 0                  0        788    1,448

[Jaouad]

Bonjour Aline ,
J'ai déja eu exactement le même cas.
Le probléme avec ces ratios c'est qu'ils sont calculés depuis le startup de la base et donc forcément lissé.
Dans mon cas il s'agissait d'un probléme de tuning de requête , car plus ca vite et plus forcément tu lache le latch repidement et moins le personne derriére attend.....

Est ce que tu t'es penché sur le code et sur l'utilisation des index et des jointures ?


Jaouad

[rouardg]

Bonjour,

Personnellement, je suis de l'avis de Jouad.

Aline, ton Top Five au sujet des Wait Events indique que le 1er événement est 'db file sequential read', indiquant souvent une lecture d'index au coup à coup.

Je pense qu'il doit y avoir au moins une requête à optimiser, ce qui devrait faire diminuer le 'cache buffers chains'.

[aline]

Bonjour Jaouad,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 car plus ca vite et plus forcément tu lache le latch repidement et moins le personne derriére attend.....

????

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Est ce que tu t'es penché sur le code et sur l'utilisation des index et des jointures ?

Il y a clairement une appli qui ralenti la base, mais qui envoie beaucoup de requêtes, toutes bindées et très très rapides.

Du coup, je ne vois pas comment l'ameliorer. Elle pose peux être des problèmes de contention, mais je n'arrive pas à voir ou.




Bonjour Rouardg,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Aline, ton Top Five au sujet des Wait Events indique que le 1er événement est 'db file sequential read', indiquant souvent une lecture d'index au coup à coup.

Il indique surement ama des problème d'I/O

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Je pense qu'il doit y avoir au moins une requête à optimiser, ce qui devrait faire diminuer le 'cache buffers chains'.

Tu veux dire le library cache?

Je pense tunner le library cache, car je n'est pas de prioblème avec mon appli qui fait du db file sequential read, mais avec les autres qui latchent.

[Jaouad]

Bonjour Jaouad,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 car plus ca vite et plus forcément tu lache le latch repidement et moins le personne derriére attend.....

????

Le cache buffer chain est un hot bloc , a savoir que ce bloc dispose d'un verrou avec deux positions pris ou pas pris , si celui est prit alors la personne réclammant également ce verrou est en mode attente d'ou du cache buffer chain comme attente.

Tu peux avoir plus de renseigement avec l'article que je t'ai donnée.

Donc plus ta requête va vite plus le verrou est relaché rapidement et moins il y a de contentions de ce type.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Est ce que tu t'es penché sur le code et sur l'utilisation des index et des jointures ?

Il y a clairement une appli qui ralenti la base, mais qui envoie beaucoup de requêtes, toutes bindées et très très rapides.

Du coup, je ne vois pas comment l'ameliorer. Elle pose peux être des problèmes de contention, mais je n'arrive pas à voir ou.

Une requête avec un index n'est pas forcément otpimisé il faut peut être revoir la requête (voir également la pertinence de l'index et de la jointure )

Lorsque tu observe du latch free est ce que tu as essayé de capturer la requête en cause.

rouardg c 'est Jaouad

[orafrance]

Il y a clairement une appli qui ralenti la base, mais qui envoie beaucoup de requêtes, toutes bindées et très très rapides.

Du coup, je ne vois pas comment l'ameliorer. Elle pose peux être des problèmes de contention, mais je n'arrive pas à voir ou.

Et pourquoi tu te lances dans du tuning alors ???

[aline]

Je ne comprens pas pourquoi vous me parlez tous du cache buffer chain alors que je n'ai pas de problème à ce niveau (je n'en ai jamais parlé).

J'ai des problèmes de library cache (peux être parce que j'ai beaucoup de db file seqsential read) ou bien des contentions au niveau des I/O????

Mais je n'ai PAS de problème avec le cache buffer chain!

[Jaouad]

Aline peut tu donner le résulat de cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT addr, latch#, gets, misses, sleeps, ROUND (((misses*100)/gets),6) AS ratio 
    FROM v$latch_children 
   WHERE sleeps>0 
     AND latch# = (SELECT latch# FROM v$latchname 
WHERE name ='cache buffers chains') 
   ORDER BY sleeps DESC

en laissant :

name ='cache buffers chains'

Merci

Jaouad

[aline]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
SELECT addr, latch#, gets, misses, sleeps, ROUND (((misses*100)/gets),6) AS ratio
    FROM v$latch_children
   WHERE sleeps>0
     AND latch# = (SELECT latch# FROM v$latchname
WHERE name ='cache buffers chains')
   ORDER BY sleeps DESC

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
1	A6A605B4	98	11318666	3657	6080	0.032309
2	A6A1C734	98	7631577	2654	1622	0.034777
3	A6A60094	98	20666111	5454	1195	0.026391
4	A6A1DBB4	98	2159223	518	979	0.02399
5	A6A65294	98	12299499	438	724	0.003561
6	A6B66B14	98	36742507	32292	712	0.087887
7	A6B90034	98	49275983	90720	679	0.184106
8	A6B90554	98	25002622	20119	543	0.080468
9	A6A1D694	98	1352541	234	454	0.017301
10	A69FBC74	98	2309352	200	440	0.00866
11	A6D565CC	98	19412783	4904	375	0.025262
12	A6E038CC	98	9329621	334	357	0.00358
13	A6E85C24	98	1269695	144	302	0.011341
14	A6E1EEDC	98	9275274	259	268	0.002792
15	A6DF115C	98	15568636	13217	255	0.084895
16	A6AD0774	98	12288300	1803	249	0.014672
17	A6B6F574	98	9182421	235	243	0.002559
18	A6E05C74	98	9657060	276	242	0.002858
19	A6DF2FEC	98	22120434	18685	239	0.084469
20	A6DF072C	98	15042966	12181	238	0.080975
.............. (3936 rows)

et voilou!

[Jaouad]

et celle ci

on va essayer de voir qu'elle est la cause de ton free latch :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  SELECT latch#, name , gets , misses , ROUND (((misses*100)/gets),6) AS ratio   FROM v$latch 
   WHERE gets !=0 
   ORDER BY 5 DESC

[Jaouad]

et tant qu'on y est celle ci aussi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT addr, latch#, gets, misses, sleeps, ROUND (((misses*100)/gets),6) AS ratio 
    FROM v$latch_children 
   WHERE sleeps>0 
     AND latch# = (SELECT latch# FROM v$latchname 
WHERE name ='cache buffers chains') 
   ORDER BY ratio DESC

[bouyao]

Bonjour Aline,

Je te conseille de lire cet article : library cache

Je suis en déplacement, demain je te donnerais mon avi
et mon prochain article ca sera sur les OWI du buffer cache (presque terminé) et un autre sur les library cache (en 9i et 10g) qu'on ne trouve pas dans la documentaion oracle.