Rapport Parse Call /Execution dans STATSPACK

[Wurlitzer]

Bonjour,

J'ai sur une base 9.2 un rapport statspack qui me donne le résultat suivant

Code :

1
2
3
4
5
6
7
 
                           % Total
 Parse Calls  Executions   Parses  Hash Value
------------ ------------ -------- ----------
       9,687        9,715     1.98  195150752
Module: XXXXX
SELECT 1 FROM XXX_XXXX WHERE PKEY = :Pkey AND etc ...

Je suis surpris d'avoir un nombre de Parse Calls proche du Nombre d'Execution.

Je me pose plusieurs questions :
- Ai je raison de trouver cela anormal (alors que j'utilise des Bind variable par cursor_sharing = similar)
- Est ce grave ? En particulier au niveau des perfs ?

Au niveau global j'ai les ration suivant qui ne sont pas non plus très beau au niveau du parse.

Code :

1
2
3
4
5
6
7
8
 
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:    100.00
            Buffer  Hit   %:   92.25    In-memory Sort %:     99.99
            Library Hit   %:   96.44        Soft Parse %:     91.57
         Execute TO Parse %:   57.47         Latch Hit %:     99.94
Parse CPU TO Parse Elapsd %:   48.32     % Non-Parse CPU:     90.02

Pareil, est ce grave ?

Merci de votre aide

[orafrance]

ça fait longtemps que la base est démarrée ?

les autres ratios paraissent bon pourtant... la SGA est peut-être trop petite pour garder les plans d'exécutions

[Wurlitzer]

En l'occurence elle a été redémarré cette nuit à 2heure du matin mais ce "problème" à été constaté aussi apres plusieurs jours de fonctionnement. Oui, les autres ratio sont pas mal et les perfs globales sont bonnes. Je me demande juste si cela ne cache pas quelque chose.

Moi aussi j'avais pensé à une SGA trop petite mais j'ai

Code :

1
2
3
4
5
6
 
 Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   69.50   69.16
    % SQL WITH executions>1:   90.42   90.38
  % Memory FOR SQL w/exec>1:   97.28   97.79

et

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
                                                          Estd
Shared Pool    SP       Estd         Estd     Estd Lib LC Time
   Size FOR  Size  Lib Cache    Lib Cache   Cache Time   Saved  Estd Lib Cache
  Estim (M) Factr   Size (M)      Mem Obj    Saved (s)   Factr    Mem Obj Hits
----------- ----- ---------- ------------ ------------ ------- ---------------
         80    .5        100        7,779       16,902     1.0       5,345,494
         96    .6        115        9,238       16,927     1.0       5,368,784
        112    .7        130       10,610       16,945     1.0       5,385,141
        128    .8        145       12,593       16,957     1.0       5,396,887
        144    .9        160       14,050       16,967     1.0       5,405,186
        160   1.0        175       15,484       16,972     1.0       5,410,782
        176   1.1        190       16,589       16,976     1.0       5,415,836
        192   1.2        205       18,116       16,980     1.0       5,420,970
        208   1.3        220       19,725       16,983     1.0       5,424,241
        224   1.4        235       21,342       16,986     1.0       5,427,899
        240   1.5        250       22,824       16,989     1.0       5,433,142
        256   1.6        265       24,165       16,991     1.0       5,436,087
        272   1.7        280       25,675       16,992     1.0       5,437,891
        288   1.8        295       27,436       16,994     1.0       5,440,102
        304   1.9        310       28,907       16,995     1.0       5,441,830
        320   2.0        399       38,255       16,995     1.0       5,442,422
          -------------------------------------------------------------

qui semble me dire que c'est Ok de ce coté la. Vous êtes d'accord avec moi ?

[orafrance]

et bien tu n'utilises encore pas assez de variable... tu as un problème particulier pour t'intéresser à ce ratio... parce qu'à moins d'avoir des contentions sur la CPU c'est pas vraiment important

[Wurlitzer]

Non, non je n'ai pas de soucis particulier. C'est juste de la curiosité. Donc comme je n'ai pas de soucis de CPU, je n'ai pas me soucier du parse. Tant mieux.

Mais je ne comprend toujours pas pourquoi dans la trace STATPACK j'ai un nombre égale de parse et d'execution. Si Statspack arrive a regrouper cette requête sous une même HASH_VALUE, c'est bien pcq j'utilise une bind variable. Si c'est le même HASH il devrait pas avoir besoin de reparser sauf si j'ai pas assez de SGA (ce qui ne semble pas être le cas).

Il y a forcément une faille dans ce raisonnement mais je ne vois pas où

[Wurlitzer]

Ca y est je crois que j'ai trouvé la faille.... Il s'agit du parametre SESSION_CACHED_CURSORS qui limite le nombre de curseur en cache et qui peut donc faire que l'on re parse des requetes déjà parsé malgré qu'il reste de la place dans la SGA.

Si je veux consomer davantage de SGA, je peux augmenter le SESSION_CACHED_CURSORS et normalement limiter le nombre de parse.

Dans mon cas SESSION_CACHED_CURSORS est 2000 ce qui me semble beaucoup et comme c'est une base de Prod qui marche pas mal alors je vais pas jouer au apprenti sorcier