Discussion :

[aline]

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
 
 SELECT latch#, name , gets , misses , ROUND (((misses*100)/gets),6) AS ratio   FROM v$latch
   WHERE gets !=0
   ORDER BY 5 DESC
1	192	job workq parent latch	313	313	100
2	114	redo copy	1761	1064	60.420216
3	19	trace latch	299	5	1.672241
4	108	archive process latch	11372	113	0.993669
5	228	fixed table rows for x$hs_session	142	1	0.704225
6	3	process allocation	122511	533	0.435063
7	96	active checkpoint queue latch	909688	3398	0.373535
8	93	cache buffers lru chain	4897517	15314	0.312689
9	15	messages	37374411	70851	0.189571
10	157	library cache	267948192	433980	0.161964
11	156	shared pool	76116727	92177	0.1211

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
 
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
 
1	A6B90034	98	50776037	91087	695	0.17939
2	A6B66B14	98	38090558	32749	766	0.085977
3	A6DF115C	98	16815644	14336	281	0.085254
4	A6DF2FEC	98	22779002	18747	244	0.082299
5	A6B90554	98	26201080	21017	617	0.080214
6	A6DF072C	98	16100959	12907	253	0.080163
7	A6C92814	98	14975957	11579	222	0.077317
8	A6DF1674	98	16420666	11459	197	0.069784
9	A6C91394	98	15234262	10377	189	0.068116
10	A6C91DD4	98	13518076	8939	169	0.066126

et revoilou!

[aline]

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.

Bonjour Bouyao,

Je l'ai déjà lu!
Peux être que mon problème est plus proche de cela http://www.ixora.com.au/q+a/0009/01134352.htm

Je m'oriente peux être à augmenter _kgl_latch_count à 5.
a tester evidement

[bouyao]

On tombe dans un cercle vicieux


Il faut essayer avec

Code :

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

CURSOR_SHARING=FORCE

sinon il faut le laisser à SIMILAR
et n'oubli pas de mettre

Code :

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

CURSOR_SPACE_FOR_TIME=TRUE

Essaye de diminuer le shared pool tu'aura des misses mais mieu qu'avant.


Pour

_kgl_latch_count

essaye de lancer cette requête pour trouver le paramètre :

Code :

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

1
2
3
4
5
6
7
SQL> select count(*) from v$latch_children where name='library cache';
 
  COUNT(*)
----------
         3
 
SQL>

C'est que j'ai vu dans le dump de l'autre tread que tu a posté 1 semaine :
Tu a beaucoup de cursors invalides (CRSCR).

[Jaouad]

Aline,
Est ce que tu as vu ces deux latchs :

1 192 job workq parent latch 313 313 100
2 114 redo copy 1761 1064 60.420216

Leur ratio est énorme , non ?

[aline]

On tombe dans un cercle vicieux


Il faut essayer avec

Code :

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

CURSOR_SHARING=FORCE

sinon il faut le laisser à SIMILAR
et n'oubli pas de mettre

Code :

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

CURSOR_SPACE_FOR_TIME=TRUE

Essaye de diminuer le shared pool tu'aura des misses mais mieu qu'avant.


Pour

_kgl_latch_count

essaye de lancer cette requête pour trouver le paramètre :

Code :

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

1
2
3
4
5
6
7
SQL> select count(*) from v$latch_children where name='library cache';
 
  COUNT(*)
----------
         3
 
SQL>

C'est que j'ai vu dans le dump de l'autre tread que tu a posté 1 semaine :
Tu a beaucoup de cursors invalides (CRSCR).

Pour répondre à toutes tes questions:

mon cursor sharing est à force ainsi que cursor_space_for_time est à true(rien à changer donc).

Pour le shared pool, je veux bien essayer mais j'ai du mal à comprendre pourquoi.

J'avais suivi ton conseil de baisser le buffer cache, mais cela n'a rien amélioré.

sinon, la requête donne evidement 3. j'ai deux processeurs donc _kgl_latch_count est à 3.
Je voudrai le passer à 2*cpu+1 donc 5.
Qu'en penses tu?

Pour les curseurs invalides, tu as raison, il y en a beaucoup bien que le pourcentage soit faible. Cela peux venir de quoi?

Aline,
Est ce que tu as vu ces deux latchs :

1 192 job workq parent latch 313 313 100
2 114 redo copy 1761 1064 60.420216

Leur ratio est énorme , non ?

oui, mais je ne pense pas que cela soit important. En effet, le nombre de gets est trob faible pour que cela soit significatif.









Je vais donc changer _kgl_latch_count puis peux être diminuer la shared pool.
Mais à mon avis(je me trompe peux être) le problème principal vient de la faiblesse de l'architecture machine J'ai vraiment l'impression que je rame au niveau des I/O. Dans mes tkprof, la différence entre mon temps cpu et elapsed est toujours gigantesque. Ce temps correcpond toujours à des lectures disques (db file sequential reads). On retrouve cette faibless dans le ratio Parse CPU to Parse Elapsd %: de mes rapports statspack (toujours en dessous de 5%).

Et contre cela, à part acheter de nouveau serveurs, je ne vois pas ce que l'on pourrai faire.....