Oracle 8i - Taille PGA

Bonjour,

Ayant déjà pu apprécié la pertinence des réponses sur ce site, j'aimerais vous soumettre ce problème.

Sur une base en 8i dont le paramètre sort_area_size est à 8Mo, j'ai plusieurs sessions qui depassent alègrement cette taille mémoire :

Code:

---

1 2 3 4 5

NAME TYPE VALUE ------------------------------------ ----------- ---------- sort_area_retained_size integer 0 sort_area_size integer 8388608

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

SID NAME TAILLE_PGA_MO QUI ---------- ------------------------------------------------------- ------------- ----- 8 session pga memory 27 Autre 9 session pga memory 80 Autre 11 session pga memory 0 Autre 14 session pga memory 5 Autre 15 session pga memory 28 Autre 18 session pga memory 0 Moi 19 session pga memory 9 Autre 21 session pga memory 115 Autre 26 session pga memory 63 Autre 27 session pga memory 44 Autre 28 session pga memory 54 Autre 29 session pga memory 0 Autre 33 session pga memory 142 Autre 34 session pga memory 10 Autre 43 session pga memory 0 Autre

---

Il me semblait que les tris étaient effectués dans la sort_area_size puis lorsque cette zone saturait sur le TS temp (avec un intial_extent et un next_extent multiple de la sort_area_size).

Code:

---

1 2 3 4 5 6

SQL> select user, extents from v$sort_usage;   USER EXTENTS ------------------------------ ---------- SYSTEM 3

---

Et ce justement pour éviter de consommer trop de RAM ...

Bon je sais bien que dans la 9i on utililse la pga_aggregate_target mais là mon problème se pose avec une 8i.

Si vous avez des éléments de réponse je suis preneur ..

Cordialement,
A.Personnat

Il s'agit probablement de variables PL/SQL qui sont allouées dans la PGA: la mémoire correspondante n'est pas prise en compte par le paramètre SORT_AREA_SIZE.

Bonjour,

Je n'aurais pas été surpris que ce soit la hash area size 22Mo ou autre zone mémoire spécifique aux algorithmes de tri, mais les variables PL/SQL, je suis un peu étonné.

Sans vouloir douter de votre réponse, serait il possible d'avoir une confirmation car 134Mo pour des variables (c'est la session 33 qui me pose problème), ça me parait un peu excessif non ?

Cordialement,
A.Personnat

L'espace mémoire des variables PL/SQL n'est pris en compte ni par SORT_AREA_SIZE, ni par HASH_AREA_SIZE ni par aucun paramètre *AREA*.
Il fait partie de la PGA que l'on ne peut pas directement règler (untunable).

Même avec Oracle 10, il est difficile d'en savoir plus comme le montre l'exemple suivant avec V$PROCESS_MEMORY.

Quelle est la requête exacte que vous utilisez pour afficher la taille de la PGA par session ?

Cet exemple est très probant (comme toujours avec T.Kytes), mais alors dans ce cas comment estimer la RAM que peut consommer une application en mode dédié sachant que je n'utilise pas de moniteur transactionnel ?

Je suis vraiment curieux de connaitre la réponse ;-)

Cordialement,
A.Personnat

Code:

---

1 2 3

taille RAM = SGA + PGA   avec PGA= sessions * (PGA fixe + PGA variable)

---

et
sessions: estimation nombre de session moyen
PGA fixe: estimation taille moyenne PGA fixe
PGA variable: estimation taille moyenne utilisée par
SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE et CREATE_BITMAP_AREA_SIZE.

Bonjour,

J'utilise une requête très proche de celle que vous mentionniez dans un post :

Code:

---

1 2 3 4 5 6 7

SELECT SUM(value) FROM v$session se, v$sesstat ss, v$statname sn WHERE ss.sid=se.sid AND sn.statistic# = ss.statistic# AND sn.name = 'session pga memory' /

---

La mienne (je ne prends pas en compte les process d'arrière plan :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

SELECT s.sid, n.name, s.value, DECODE( ses.audsid, USERENV('sessionid'), 'Moi', 'Autre') qui FROM v$sesstat s, v$statname n, v$session ses WHERE s.statistic# = n.statistic# AND n.name IN ('session pga memory') AND ses.sid = s.sid AND type != 'BACKGROUND' ORDER BY s.sid /

---

Je reviens à mon process de 142 Mo (session 33) :

Estimation de la PGA variable 43 Mo découpé comme suit :

Code:

---

1 2 3 4 5 6

sort area size 8Mo sort area retained size 0Mo bitmap_merge_area_size 1Mo create_bitmap_area_size 8Mo hash_area_size 26Mo

---

Ce qui veut dire 99Mo en PGA fixe, dans ce cas quel est le paramètre d'initialisation de cette PGA fixe, de plus je devrais retrouver cette taille pour les autre process si c'est une partie fixe, or ce n'est pas le cas.

Pourriez-vous m'éclairer sur ce point ?

En vous remerciant,
A.Personnat

Une meilleure requête pour afficher la PGA utilise V$PROCESS:

Code:

---

1 2 3

select sid, pid, pga_alloc_mem from v$session , v$process where paddr = addr;

---

Pour la taille totale de la PGA utilisée, il faut aussi prendre en compte les processus d'arrière-plan Oracle dont certains peuvent utiliser une vingtaine de Mo de PGA.

Quand je parle de PGA fixe, je parle de la PGA que l'on ne peut pas configurer directement avec un paramètre *AREA* ou PGA_AGGREGATE_TARGET; je ne veux pas dire que cette partie de la PGA a toujours une taille fixe. D'après le Concept Guide, cette PGA non configurable comprend:
- private SQL areas (bind information and runtime memory structures)
- des données internes à la session (session memory) dont doit faire partie les variables PL/SQL.

La partie non configurable de la PGA semble dépendre donc du paramètre OPEN_CURSORS, du nombre de requêtes exécutées, de la façon dont le code applicatif ferme ou non les curseurs associés à ces requêtes et aussi du code PL/SQL utilisé.

Bonjour,

Je viens de vérifer le nombre de curseurs ouverts sur cette session, il y en a 22 (session 33) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1 ora817 0 2 ora817 0 3 ora817 0 4 ora817 0 5 ora817 0 6 ora817 0 11 VISU ora817 1 18 SYSTEM ora817 1 19 VISU ora817 2 29 VISU ora817 1 33 SIGP ora817 22 34 VISU ora817 1 38 RV_EN ora817 0 43 GMA_CONSULT ora817 4

---

J'ai le sentiment que certains curseurs ne sont jamais fermés car la taille de cette session ne redescend pas (la base est ouverte 24/24 7/7).

Est ce qu'il est possible de creuser un peu plus, connaitre par exemple la taille de chaque curseur et le code associé ?

Merci,
A.Personnat

Citation:

---

Envoyé par apersonnat

Est ce qu'il est possible de creuser un peu plus, connaitre par exemple la taille de chaque curseur et le code associé ?

---

Je crois qu'il y a une possibilité de tracer les appels d'allocation et de libération de la mémoire de la PGA. Mais je ne sais pas si l'interprêtation de la trace en elle-même est documentée.

Il est peut-être plus facile d'avoir une trace dans le code applicatif et d'essayer de savoir pourquoi certains curseurs ne sont pas fermés ...

Bonjour,

Je viens de faire un check des curseurs, seulement 2 curseurs ouverts sur la session 33 et pourtant la session consomme autant de mémoire.

J'en conclus donc que la pga n'est jamais libérée sauf si je kill la session, ce qui est un peu embetant :?

Quoi qu'il en soit je vous remercie pour vos réponses et je vous souhaite un excellent week end.

Bien amicalement,
A.Personnat