[Dba] Library Cache Latch

Version imprimable

Bonjour,

J'ai des pics d'activités sur une base ces temps ci qui bloquent completement tout.
Les rapports Statspack me montrent énormement de latch free.
cela correspond à du library cache et plus particulierement;

Code:

1
2
3
4
5
 
ibrary cache            kglpndl: child: before pro       0      2,646    3,298
library cache            kglpndl: child: after proc       0      2,053       42
library cache            kglhdgn: child:                  0      1,473    2,568
library cache            kglpnp: child                    0      1,231    2,094

Je n'arrive pas à trouver une application qui pourrait être en cause.
Mais des requetes toutes simples (sur une table d'une ligne par exemple) peuvent durer plusieurs secondes (phase d'initialisation très importante).

Donc, je ne sait pas si c'est du codde pourri ou un mauvais paramètrage ou autre chose qui est en cause.

Mais j'ai quand même mis une trace sur une application assez importante pour voir ce qui se passait au niveau session.

Code:

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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
 
 
 
********************************************************************************
 
INSERT INTO PRIX_PRODUIT (PRODUIT, DATE, PRIX, NOMBRE)
VALUES
 (:B6 , :B5 , :B4 , :B3 , :B2 , :B1 )
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute  48372     15.47     245.57        875       3383     750261       48372
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    48372     15.47     245.57        875       3383     750261       48372
 
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 45     (recursive depth: 1)
 
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                       875        0.82         22.85
  latch free                                    377        2.90         17.20
  log file switch completion                     26        0.97         11.38
  log file sync                                 925        1.27         61.87
  log buffer space                               36        0.97         10.17
  buffer busy waits                               2        0.35          0.35
********************************************************************************
********************************************************************************
 
call LOAD.SET_PRIX_PRODUIT (:1, :2, :3, :4)
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute  48372      9.63      77.70          4         77        149           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    48372      9.63      77.70          4         77        149           0
 
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 45
 
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  latch free                                   2343        6.18        184.44
  SQL*Net message to client                   48372        0.00          0.07
  SQL*Net message from client                 48372        0.68         41.77
********************************************************************************
=====================
PARSING IN CURSOR #5 len=53 dep=0 uid=45 oct=170 lid=45 tim=1114550297451030 hv=1663224314 ad='b5b6a250'
call LOAD.SET_PRIX_PRODUIT (:1, :2, :3, :4, :5, :6)
END OF STMT
EXEC #5:c=0,e=99727,p=0,cr=7,cu=17,mis=1,r=0,dep=0,og=4,tim=1114550297451025
WAIT #5: nam='latch free' ela= 981 p1=-1418751532 p2=157 p3=0
WAIT #5: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #5: nam='SQL*Net message from client' ela= 369 p1=1413697536 p2=1 p3=0
WAIT #6: nam='latch free' ela= 3511 p1=-1418751732 p2=157 p3=0
=====================
 
 
EXEC #5:c=0,e=3779739,p=2,cr=7,cu=15,mis=0,r=0,dep=0,og=4,tim=1114550341383273
WAIT #5: nam='latch free' ela= 14577 p1=-1418751332 p2=157 p3=0
WAIT #5: nam='latch free' ela= 157552 p1=-1418751532 p2=157 p3=0
WAIT #5: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #5: nam='SQL*Net message from client' ela= 1466 p1=1413697536 p2=1 p3=0
 
 
EXEC #5:c=0,e=79520,p=1,cr=7,cu=15,mis=0,r=0,dep=0,og=4,tim=1114550341878306
WAIT #5: nam='latch free' ela= 7322 p1=-1418751332 p2=157 p3=0
WAIT #5: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #5: nam='SQL*Net message from client' ela= 4726 p1=1413697536 p2=1 p3=0

Ce qui est bizarre, c'est que c'est l'appel à la procédure qui prends le library latch.

Evidement, ce n'est pas ce code qui est responsable, il subit plus qu'autre chose.

Le taux de bind est assez elevé (entre 96 et 99% selon les tranches horaires).

quelqu'un a une idée?

02/03/2006, 17h52
Jaouad

aline ,
il y a quand même une grande différence entre lepsed et CPU , la machine n'est pas surchargé ???
02/03/2006, 18h10
aline

bonjour Jaouad,

Evidement qu'elle est chargée!
Pendant ces pics d'activitée, le load monte à plus de 12.
Faire un vi sur un fichier devient presque problematique!

Mais c'est l'effet et non pas la cause, enfin je pense...
02/03/2006, 21h07
orafrance

et un top des process consommateurs donne quoi ?
02/03/2006, 23h01
aline

Citation:

Envoyé par Fred_D

et un top des process consommateurs donne quoi ?

Salut Fred,
Je ne suis pas sûre de comprendre ce que tu dis.
Le load sur la machine monte à plus de 12.
quand je fais un top, je n'ai pas l'impression de voir un process plus consomateur que les autres...
03/03/2006, 10h10
orafrance

quand tu regardes la liste des process de l'OS, est-ce que c'est bien Oracle qui est consommateur ou alors tu as des trucs qui consomment à coté ?
03/03/2006, 10h30
Jaouad

il y a forcément quelque chose a coté parce que oracle ne comsomme pas tout le CPU
03/03/2006, 10h52
aline

non, cette machine est dediée à Oracle, donc, il prends tout le cpu.
c'est ce que j'obesrve d'ailleurs quand je fais un top.
Les seuls process actifs sont des process oracle
03/03/2006, 10h59
Jaouad
on est d'accord, mais si cette machine est dédié à Oracle , le CPU et elapsed doivent être similaire.

La différence vient du fait que pour cette reuqête :
Code:

1 2 3 INSERT INTO PRIX_PRODUIT (PRODUIT, DATE, PRIX, NOMBRE) VALUES (:B6 , :B5 , :B4 , :B3 , :B2 , :B1 )
qui dure 245 secondes ( plus de 4 minutes ), l'opération en soit ne dure que 15 sec.

Tu fais un top dans une fenêtre et tu récupére le PID de la session qui consomme le plus.

tu peux retrouver le SID et donc la requête grace à ) la vue v$process et v$session

et tu vois quel est la requête la plus consomatrice

Citation:

Envoyé par Jaouad

on est d'accord, mais si cette machine est dédié à Oracle , le CPU et elapsed doivent être similaire.

Je suis d'accord.
J'avais déjà posé un post car j'ai toujours une énorme différence entre les deux (cpu et elapsed) dans beaucoup de mes requêtes. et ce, des qu'il y a des I/O.

Citation:

Envoyé par Jaouad

Tu fais un top dans une fenêtre et tu récupére le PID de la session qui consomme le plus.

tu peux retrouver le SID et donc la requête grace à ) la vue v$process et v$session

et tu vois quel est la requête la plus consomatrice

Oui (et même l'étape 2 n'est pas nécessaire avec oradebug!), c'est ce que je fait.
Le problème est de fliquer toutes les petites intrusions (connection,requete,deconnection) potentiellements lourdes.

en tout cas, j'utilise déjà ce genre d'outils, mais cela ne m'a rien donné.

La partie interessente dans ma session qui subit les attentes, ama, c'est:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 call LOAD.SET_PRIX_PRODUIT (:1, :2, :3, :4) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 48372 9.63 77.70 4 77 149 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 48372 9.63 77.70 4 77 149 0 Misses in library cache during parse: 0 Misses in library cache during execute: 1 Optimizer goal: CHOOSE Parsing user id: 45 Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ latch free 2343 6.18 184.44 SQL*Net message to client 48372 0.00 0.07 SQL*Net message from client 48372 0.68 41.77 ********************************************************************************
et la, on voit que c'est l'appel à la procédure qui prend un temps fou!

03/03/2006, 12h59
pifor

Un taux élevé de latch free peut venir de requêtes qui n'utilisent pas de bind variables: en PL/SQL ce n'est possible que si on fait du SQL dynamique avec EXECUTE IMMEDIATE ou avec le package DBMS_SQL.
Est-ce le cas ?

Je remarque aussi qu'il y a pas mal d'échange réseau

Citation:

SQL*Net message from client

avec une attente assez importante côté serveur. La procédure LOAD.SET_PRIX_PRODUIT (:1, :2, :3, :4) est-elle appelée par le client ? Le client est-il ou non sur la même machine que le serveur (si oui, il faudrait éviter de passer par le couche TCP mais plutôt par les IPC).
03/03/2006, 14h24
Jaouad

Citation:

Envoyé par pifor

Un taux élevé de latch free peut venir de requêtes qui n'utilisent pas de bind variables: en PL/SQL ce n'est possible que si on fait du SQL dynamique avec EXECUTE IMMEDIATE ou avec le package DBMS_SQL.
Est-ce le cas ?.

Il faut déja déterminer le latch sur lequel on attend ...