Rapport Parse Call /Execution dans STATSPACK

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

ç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 :koi:

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 ?

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 ;)

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ù :koi:

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 :mrgreen: