[Oracle 8i][Internet] Shared Pool Size

Version imprimable

02/11/2004, 14h45
dupin40

[Oracle 8i][Internet] Shared Pool Size

Bonjour,

J'ai un site internet développé en ASPX qui accède a une base de données oracle version 8.1.7.0.
Et depuis quelque temps, j'ai des erreurs qui reviennent régulièrement :

Citation:

ORA-04031: unable to allocate 4200 bytes of shared memory ("shared pool","TRIGGER$","sga heap","state objects")
ORA-00604: error occurred at recursive SQL level 2
ORA-04031: unable to allocate 4200 bytes of shared memory ("shared pool","SEQ$","sga heap","state objects")

voici la pile d'appel qui provoque l'erreur Oracle :

Citation:

Oracle Erreur :604
Trace : at System.Data.OracleClient.DBObjectPool.GetObject(Object owningObject, Boolean& isInTransaction)
at System.Data.OracleClient.OracleConnectionPoolManager.GetPooledConnection(String encryptedConnectionString, OracleConnectionString options, OracleConnection owningObject, Boolean& isInTransaction)
at System.Data.OracleClient.OracleConnection.OpenInternal(OracleConnectionString parsedConnectionString, Object transact)
at System.Data.OracleClient.OracleConnection.Open()

J'ai l'impression que le problème intervient quand je tente d'ouvrir une connexion avec le serveur Oracle. Pourtant voici ce que je fais partout dans mon code :
- j'ouvre une connexion ... connexion.open();
- je fait mon traitement ... Procédures stockées (par exemple)
- fin du traitement .... connexion.dispose();
(le dispose en interne fait un close() puis "détruit" la connexion)

Est ce que quelqu'un a déjà été confronté a ce problème et pourrait m'expliquer les raisons, et les corrections a apporter ? :help:
02/11/2004, 15h04
Yorglaa

Vraissemblablement il s'agit d'un manque de mémoire aloué la base Oracle.

Essaye d'augmenter la taille de la shared_pool de ta base (nécéssite un redémarrage :cry: ) et vérifie ensuite que ces problèmes ne sont plus rencontrés...

comme cause, tu as probablement eu une augmentation du nb de users sur cette base, ou alors des nouvelles procédures stockées qui consomment plus de ressources...

Je suis d'accord avec Yorglaa sur le principe,

Est-ce-que tu peux lancer la procédure suivante pour en être sûr :

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
 
   procedure p_shared_pool_stats as
      object_mem     number;
      shared_sql     number;
      cursor_mem     number;
      mts_mem        number;
      used_pool_size number;
      free_mem       number;
      pool_size      varchar2(512);
   begin
      -- Stored objects (packages, views)
      select   sum(sharable_mem)
      into     object_mem
      from     V$DB_OBJECT_CACHE;
 
      -- Shared SQL
      -- need to have additional memory if dynamic SQL used
      select   sum(sharable_mem)
      into     shared_sql
      from     V$SQLAREA;
 
      -- User Cursor Usage
      -- run this during peak usage.
      --  assumes 250 bytes per open cursor, for each concurrent user.
      select   sum(250*users_opening)
      into     cursor_mem
      from     V$SQLAREA;
 
      -- For a test system
      -- get usage for one user, multiply by # users
      -- select (250 * value) bytes_per_user
      -- from v$sesstat s, v$statname n
      -- where s.statistic# = n.statistic#
      -- and n.name = 'opened cursors current'
      -- and s.sid = 25;
      -- where 25 is the sid of the process
      -- MTS memory needed to hold session information for shared server users
      -- This query computes a total for all currently logged on users (run
      --  during peak period). Alternatively calculate for a single user and
      --  multiply by # users.
      select   sum(value) into mts_mem
      from     V$SESSTAT s, V$STATNAME n
      where    s.statistic# = n.statistic# and
               n.name = 'session uga memory max';
 
      -- Free (unused) memory in the SGA: gives an indication of how much memory
      -- is being wasted out of the total allocated.
      select   sum(bytes)
      into     free_mem
      from     V$SGASTAT
      where    name = 'free memory';
 
      -- For non-MTS add up object, shared sql, cursors and 20% overhead.
      used_pool_size := round(1.2*(object_mem+shared_sql+cursor_mem));
 
      -- For MTS mts contribution needs to be included (comment out previous line)
      -- used_pool_size := round(1.2*(object_mem+shared_sql+cursor_mem+mts_mem));
      select   value
      into     pool_size
      from     V$PARAMETER
      where    name = 'shared_pool_size';
 
      -- Display results
      dbms_output.put_line ('Obj mem                         :  '|| to_char(object_mem, '999G999G999G999') || ' bytes');
      dbms_output.put_line ('Shared sql                      :  '|| to_char(shared_sql, '999G999G999G999') || ' bytes');
      dbms_output.put_line ('Cursors                         :  '|| to_char(cursor_mem, '999G999G999G999') || ' bytes');
      --dbms_output.put_line ('MTS session                     : '||to_char(mts_mem, '999G999G999G999') || ' bytes');
      dbms_output.put_line ('Free memory                     :  '|| to_char(free_mem, '999G999G999G999') || ' bytes ' || '('  || to_char(round(free_mem/1024/1024,2)) || 'MB)');
      dbms_output.put_line ('Shared pool utilization (total) :  '|| to_char(used_pool_size, '999G999G999G999') || ' bytes ' || '(' ||  to_char(round(used_pool_size/1024/1024,2)) || 'MB)');
      dbms_output.put_line ('Shared pool allocation (actual) :  '|| to_char(to_number(pool_size), '999G999G999G999') ||' bytes ' || '(' || to_char(round(pool_size/1024/1024,2)) || 'MB)');
      dbms_output.put_line ('Percentage Utilized             :  '|| to_char(round(used_pool_size/pool_size*100)) || '%');
   end;

Laly.

Salut Laly...
j'ai testé ta procédure (par curiosité) et j'ai le résultat suivant :
Code:

1 2 3 4 5 6 7 8 Obj mem : 186.919.835 bytes Shared sql : 82.644.871 bytes Cursors : 3.954.000 bytes Free memory : 104.567.268 bytes (99,72MB) Shared pool utilization (total) : 328.222.447 bytes (313,02MB) Shared pool allocation (actual) : 285.212.672 bytes (272MB) Percentage Utilized : 115%
Comment ça ce fait que j'aie une utilisation de 115 % de la mémoire ? je dois pas avoir tout compris alors...

Code:

1 2 3 4 5 6 7 Obj mem : 32.079.363 bytes Shared sql : 19.593.424 bytes Cursors : 44.375 bytes Free memory : 3.496.496 bytes (3,33MB) Shared pool utilization (total) : 62.060.594 bytes (59,19MB) Shared pool allocation (actual) : 50.154.995 bytes (47,83MB) Percentage Utilized : 124%
:cry: moi non plus je comprends pas trop ...

par curiosité quels sont les params de ton init ?

Mais de toute manière je crois que je vais augmenter sensiblement (x4) mon shared_pool_size (j'ai un serveur avec 1 Go en RAM), je vais mettre 200 Mo.
Comment estime t'on la taille de la memoire alloué pour oracle ? Je me doute que ya pas de formule mathématique ... :D, mais peut etre qu'une estimation est possible ?

02/11/2004, 15h34
orafrance

regardez le script et adaptez le si vous êtes en MTS ;)
02/11/2004, 15h39
Yorglaa

non, non... pas de MTS pour moi...

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
82
83
84
85
86
87
set serveroutput on size 10000
set verify off
ACCEPT MTS_mode PROMPT 'MTS ou non ? (Y/N) ' DEFAULT N
declare 
     object_mem     number; 
      shared_sql     number; 
      cursor_mem     number; 
      mts_mem        number; 
      used_pool_size number; 
      free_mem       number; 
      pool_size      varchar2(512); 
   begin 
      -- Stored objects (packages, views) 
      select   sum(sharable_mem) 
      into     object_mem 
      from     V$DB_OBJECT_CACHE; 
 
      -- Shared SQL 
      -- need to have additional memory if dynamic SQL used 
      select   sum(sharable_mem) 
      into     shared_sql 
      from     V$SQLAREA; 
 
      -- User Cursor Usage 
      -- run this during peak usage. 
      --  assumes 250 bytes per open cursor, for each concurrent user. 
      select   sum(250*users_opening) 
      into     cursor_mem 
      from     V$SQLAREA; 
 
      -- For a test system 
      -- get usage for one user, multiply by # users 
      -- select (250 * value) bytes_per_user 
      -- from v$sesstat s, v$statname n 
      -- where s.statistic# = n.statistic# 
      -- and n.name = 'opened cursors current' 
      -- and s.sid = 25; 
      -- where 25 is the sid of the process 
      -- MTS memory needed to hold session information for shared server users 
      -- This query computes a total for all currently logged on users (run 
      --  during peak period). Alternatively calculate for a single user and 
      --  multiply by # users. 
      select   sum(value) into mts_mem 
      from     V$SESSTAT s, V$STATNAME n 
      where    s.statistic# = n.statistic# and 
               n.name = 'session uga memory max'; 
 
      -- Free (unused) memory in the SGA: gives an indication of how much memory 
      -- is being wasted out of the total allocated. 
      select   sum(bytes) 
      into     free_mem 
      from     V$SGASTAT 
      where    name = 'free memory'; 
 
      select used_pool_size
      into   used_pool_size
      from   (
	      -- For non-MTS add up object, shared sql, cursors and 20% overhead. 
	      select round(1.2*(object_mem+shared_sql+cursor_mem)) used_pool_size
	      from   dual
	      where  '&MTS_mode' = 'N'
	      UNION
	      -- For MTS mts contribution needs to be included (comment out previous line) 
	      -- used_pool_size := round(1.2*(object_mem+shared_sql+cursor_mem+mts_mem)); 
	      select round(1.2*(object_mem+shared_sql+cursor_mem+mts_mem)) used_pool_size
	      from   dual
	      where  '&MTS_mode' = 'Y'
	     );
 
      select   value 
      into     pool_size 
      from     V$PARAMETER 
      where    name = 'shared_pool_size'; 
 
      -- Display results 
      dbms_output.put_line ('Obj mem                         :  '|| to_char(object_mem, '999G999G999G999') || ' bytes'); 
      dbms_output.put_line ('Shared sql                      :  '|| to_char(shared_sql, '999G999G999G999') || ' bytes'); 
      dbms_output.put_line ('Cursors                         :  '|| to_char(cursor_mem, '999G999G999G999') || ' bytes'); 
      IF '&MTS_MODE' = 'Y' THEN
      	dbms_output.put_line ('MTS session                     : '||to_char(mts_mem, '999G999G999G999') || ' bytes'); 
      END IF;
      dbms_output.put_line ('Free memory                     :  '|| to_char(free_mem, '999G999G999G999') || ' bytes ' || '('  || to_char(round(free_mem/1024/1024,2)) || 'MB)'); 
      dbms_output.put_line ('Shared pool utilization (total) :  '|| to_char(used_pool_size, '999G999G999G999') || ' bytes ' || '(' ||  to_char(round(used_pool_size/1024/1024,2)) || 'MB)'); 
      dbms_output.put_line ('Shared pool allocation (actual) :  '|| to_char(to_number(pool_size), '999G999G999G999') ||' bytes ' || '(' || to_char(round(pool_size/1024/1024,2)) || 'MB)'); 
      dbms_output.put_line ('Percentage Utilized             :  '|| to_char(round(used_pool_size/pool_size*100)) || '%'); 
   end; 
/

02/11/2004, 15h41
dupin40

Citation:

Envoyé par orafrance

regardez le script et adaptez le si vous êtes en MTS ;)

:oops: :oops: C'est quoi MTS ?? :oops: :oops:
02/11/2004, 15h42
orafrance

Citation:

Envoyé par dupin40

Citation:

Envoyé par orafrance

regardez le script et adaptez le si vous êtes en MTS ;)

:oops: :oops: C'est quoi MTS ?? :oops: :oops:

multi-thread server ;)

je te renvoie à la doc pour plus de détails ;)

En gros, au lieu d'avoir une session par connection, tu crées un pool de connection :)

Je crois que ca vient de l'approximation de multiplier par 120% pour avoir la taille réellement utilisée.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
SQL> exec pkg_tuning.p_shared_pool_stats;
Obj mem                         :         4.804.983 bytes
Shared sql                      :         3.984.533 bytes
Cursors                         :             6.375 bytes
Free memory                     :        51.455.972 bytes (49,07MB)
Shared pool utilization (total) :        10.555.069 bytes (10,07MB)
Shared pool allocation (actual) :        10.000.000 bytes (9,54MB)
Percentage Utilized             :  106%
 
PL/SQL procedure successfully completed.
 
REM après suppression de la multiplication par 1.20
SQL> exec pkg_tuning.p_shared_pool_stats;
Obj mem                         :         5.290.271 bytes
Shared sql                      :         4.387.256 bytes
Cursors                         :             5.375 bytes
Free memory                     :        51.323.568 bytes (48,95MB)
Shared pool utilization (total) :         9.682.902 bytes (9,23MB)
Shared pool allocation (actual) :        10.000.000 bytes (9,54MB)
Percentage Utilized             :  97%
 
PL/SQL procedure successfully completed.

C'est dommage, j'ai plus la source...

En tout cas, si ca dépasse autant c'est qu'effectivement il faut agrandir le shared pool.

Laly.

02/11/2004, 15h50
Yorglaa

Etrange !!

si je reprends mes chiffres, j'ai 115 % d'utilisation avec 99 MB de libre...

alors avec autant de libre je ne vois pas d'utilité à agrandir le shared_pool... bien au contraire une shared_pool trop grande n'est pas bonne non plus avec la fragmentation de la mémoire...
02/11/2004, 15h52
orafrance

Pour répondre à l'utilisation supérieur à 100% c'est très simple, ce script n'est qu'un estimation de l'espace utilisée. D'ailleurs on voit :

used_pool_size := round(1.2*(object_mem+shared_sql+cursor_mem))

et on peut lire dans les commentaires : 20% overhead

ça veut simplement dire qu'on ne peut pas savoir l'espace occupé à un instant t dans la SGA. Néanmoins, si vous avez plus de 100% on peut considérer que vous êtes plus que juste et qu'il faudrait penser à augmenter SHARED_POOL_SIZE ;)

Pour en être sûr, il faut passer par statpack qui lui donne les valeurs exactes relevées entre deux snapshot ;)
02/11/2004, 15h53
orafrance

Citation:

Envoyé par Yorglaa

Etrange !!

si je reprends mes chiffres, j'ai 115 % d'utilisation avec 99 MB de libre...

alors avec autant de libre je ne vois pas d'utilité à agrandir le shared_pool... bien au contraire une shared_pool trop grande n'est pas bonne non plus avec la fragmentation de la mémoire...

tu as la réponse dans la question... 99Mb de libre c'est bien mais si c'est fragmenté comme pas possible, ça ne sert à rien :?
02/11/2004, 15h56
lalystar

Yorglaa,

Les 99Mo de libre c'est de la mémoire allouée à la SGA mais inutilisée. Ce n'est pas du Shared Pool inutilisé, je sais pas s'il y a ambiguite.

Laly.
02/11/2004, 16h14
dupin40

Merci a tous pour ces informations ...

donc si j'ai bien compris.
:arrow: Cette procédure donne une estimation de l'allocation de la mémoire partagées pour Oracle, ainsi que son utilisation.
:arrow: si on dépasse 100 %, c'est qu'il faut augmenter le SHARED_POLL_SIZE

Encore une question : Y a t'il un moyen de savoir pourquoi le shared_pool_size est si important ??
02/11/2004, 16h18
orafrance

oui :

Code:

select * from v$sgastat;
02/11/2004, 16h21
Yorglaa

Citation:

Envoyé par lalystar

Les 99Mo de libre c'est de la mémoire allouée à la SGA mais inutilisée. Ce n'est pas du Shared Pool inutilisé, je sais pas s'il y a ambiguite..

oups... en effet je me suis un peu marché sur l'sac ce coup-ci... sorry

je vais creuser une peu alors... mais ça doit pas être dramatique parcequ'on a de bonnes performances sur cette base...
02/11/2004, 17h49
dupin40

Merci a tous pour votre aide.

Je modifie les paramètres sur le serveur et je vous tiens au courant si j'ai d'autre problèmes.
:merci:
02/11/2004, 22h02
lalystar

Citation:

Y a t'il un moyen de savoir pourquoi le shared_pool_size est si important ??

Je dirais qu'il y a des chances que tu n'utilises pas les binds variables.

Laly.
03/11/2004, 11h48
dupin40

je viens de retirer le tag RESOLU :cry:

Je vais passer pour un débutant, mais que sont les binds variables ?
Deuxième question : Le % ne fait qu'augmenter avec l'utilisation de la base,
Y a t'il un moyen de libérer cette memoire allouée mais non utilisée ... une sorte de Garbage Collector pour ORACLE ? ou bien la seule solution est de redémarrer l'instance de la base.
03/11/2004, 11h59
orafrance
les bind variables sont simplement des variables qui remplace des valeurs en dur.

Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 DECLARE dummy NUMBER; BEGIN SELECT 1 INTO dummy FROM all_tables WHERE table_name = 'TOTO'; END; /
devient :
Code:

1 2 3 4 5 6 7 8 9 10 11 DECLARE dummy NUMBER; tab_name VARCHAR2(30) := 'TOTO' BEGIN SELECT 1 INTO dummy FROM all_tables WHERE table_name = tab_name; END; /
ainsi Oracle reconnait la requête quelque soit la valeur de tab_name alors que dans le premier exemple, Oracle considère que si 'TOTO' devient 'TITI' la requête est différente.
03/11/2004, 12h06
Marc Musette

1) vérifie que tu as bien le dernier patch installé pour ta version db (il y a des bugs aussi chez oracle --> vérifie via ton compte metalink)

2) si pas de bug, ton problème vient de ton applic : elle doit être mal écrite ... tu dois effectivement utiliser des bind variable dans tes statements plutôt que des valeurs en dur

te faire un cour sur les bind variable me semble difficille, je crois qu'il y a un article de sheik yerbouti à ce sujet sur ce forum

le principe sous-jacent à ces bind variable est que lorsque tu exécutes un statement, oracle le cache en mémoire et à la prochaine exécution, il le réutilise ... SSI il est identique --> les bind variable permette de passer des valeurs différentes à un même sql

l'exemple le pus concret d'une bind variable est une variable pl/sql

ton problème de mémoire n'est pas forcément dû à une taille trop petite mais à un problème de fragmentation

-> réécrire l'applic ... semble la bonne solution
-> peut-être configurer le shared reserved pool mais là il faut relire la doc car je ne fais pas cela tous les jours (en gros, c'est une zone mémoire hors de la library cache où tu peux stocker certains objets et les rendre hors de porté du fameux algorithme LRU de la library cache)

pour tenter de résoudre très temporairement ton pblm tu peux faire un flush du shared pool --> alter system flush shared pool

mais le problème c'est ton applic , ou un bug ...

j'ai bien compris ce que sont les binds variables ... cf ce lien
enfin je crois
- pour tout query envoyé au serveur, le gestionnaire regarde si en cache le query n'existe pas exactement au niveau des la synthaxe.
- ok
on va dire que dans la majorité des cas, lorsque je dois executer une requete je le fais de cette maniere .... synthaxe C# / ASPX
Code:

1 2 3 4 5 6 OracleConnection conn = new OracleConnection(...); OracleDataAdapter cmd = new OracleDataAdapter("select nom, prenom from employe where id = :monid", connexion); cmd.SelectCommand.Parameters.Add("monid", 12); ... conn.Dispose();
Donc a priori j'utilise les variables liées "bind varaibles". non ?

03/11/2004, 12h51
orafrance

probablement pas puisque C# doit remplacer la variable par sa valeur avant d'envoyer la requête à Oracle :?
03/11/2004, 12h59
dupin40

Citation:

Envoyé par orafrance

probablement pas puisque C# doit remplacer la variable par sa valeur avant d'envoyer la requête à Oracle :?

:arf: il va falloir quand meme vérifier !! c'est pas possible !!
03/11/2004, 13h17
Marc Musette

ben oui ...

utilise odp.net
03/11/2004, 14h33
dupin40

Citation:

Envoyé par Marc Musette

ben oui ...

utilise odp.net

Oups, j'utilise ceux de "Microsoft .NET Framework 1.1 Data Provider for Oracle" intégré à Visual Studio 2003

Il y a une différence importante entre ces deux Providers ?
car odp.net n'est dispo que pour Oracle9i et au dessus reference MSDN
03/11/2004, 14h37
lalystar
dupin40,

vu le bout de code que tu fournis je pense que tu utilises les bind variables.

Pour en être sûr, tu peux faire :
Code:

1 2 3 -- vide le contenu du shared pool alter system flush shared_pool;
Puis lance par ton code, deux requêtes différent seulement par une constante.

Et ensuite regarde dans V$SQL tu as combien de requêtes.

Laly.
03/11/2004, 14h53
orafrance

laly :arrow: je ne pense pas... d'ailleur :

Code:

execute immediate 'select owner from table_name where table_name = ' || ma_var;

n'utilise pas les bind variables... attention donc ;)
03/11/2004, 16h15
lalystar
Orafrance,

Je suis entièrement d'accord avec toi : ton exemple n'utilise pas les bind variables mais sur le principe je pensais que le bout de code de dupin40 est équivalent à :
Code:

1 2 execute immediate 'select owner from table_name where table_name = :1' using ma_var;
Car les valeurs des paramètres sont fournies par le md.SelectCommand.Parameters.Add.

j'ai un bout de code en VB au travail qui utilise les binds variables, je regarderais demain.

Laly.
03/11/2004, 16h19
orafrance

oui peut-être... finalement j'en sais rien du tout, je ne connais absolument pas C# :aie:

Oui en fait mon bout de code est différent sur le principe puisque je ne recrée pas les paramètres de l'objet commande :

En visual basic, pour utiliser les bind variables :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
    Dim cmd As ADODB.Command
    Set cmd = New ADODB.Command
    With cmd
        .ActiveConnection = cnx
        .CommandText = "insert into W_CTE_CTI_MC_COVERAGE values(?, ?)"
 
        .CreateParameter "client_id", adInteger, adParamInput, 7
        .CreateParameter "i_intrn", adVarChar, adParamInput, 18
    End With
 
    While ...
            With cmd
                .Parameters(0).Value = clientId
                .Parameters(1).Value = rmpm
                .Execute
            End With
    Wend

Laly.

04/11/2004, 11h36
dupin40

Plus de problème depuis que j'ai patché la base Oracle 8.1.7.0 -> 8.1.7.4
avec le dernier patch pour oracle 8i. :D

Maintenant je m'interesse au remplissage de cette fameuse Shared_Pool
avec la commande

Code:

select * from v$SQL;

je liste le contenu de celle ci et je trouve dans chose un peu bizarre mais je suis certain que nos redacteurs vont pouvoir m'aider :wink:

Comment deux query identiques (même SQL_TEXT) peuvent se trouver deux fois dans la Shared_Pool. :?

Citation:

select distinct M2_C1,M2_C2,M2_C82,M2_C83,M2_C10 from M2 where M2_C3=0 and M2_C5='T' order by M2_C82 ASC
select distinct M2_C1,M2_C2,M2_C82,M2_C83,M2_C10 from M2 where M2_C3=0 and M2_C5='T' order by M2_C82 ASC
04/11/2004, 11h42
orafrance
tu peux vérifier si elles sont identiques à l'espace près... parce que si je ne me trompe pas :

Code:

select sysdate from dual;

et
Code:

1 2 select sysdate from dual;
sont différentes... je vais essayer de retrouver l'article qui parle de ça ;)
04/11/2004, 11h46
lalystar

Quand tu regardes V$SQLAREA, tu as une colonne VERSION_COUNT qui contient le nb de versions existants pour une même requête.

En effet, une même requête peut être traitée de manière différente quand l'environnement n'est pas le même (paramètres de session par exemple : SORT_AREA_SIZE, HASH_AREA_SIZE, OPTIMIZER_GOAL...)

Laly.
04/11/2004, 11h56
dupin40

Je suis quasiment certains que les deux queries sont identiques car j'ai copier coller le resultat de la requete
depuis PL/SQL Developer ... :? A moins que PL/SQL Developper ou que je la vue ne reformatte les données ... Je vais approfondir en regardant dans mon code.
Merci je poursuis mes recherches :D
04/11/2004, 12h04
dupin40

Citation:

Envoyé par lalystar

Quand tu regardes V$SQLAREA, tu as une colonne VERSION_COUNT qui contient le nb de versions existants pour une même requête.

En effet, une même requête peut être traitée de manière différente quand l'environnement n'est pas le même (paramètres de session par exemple : SORT_AREA_SIZE, HASH_AREA_SIZE, OPTIMIZER_GOAL...)

Laly.

Bien compris.
Donc dans le code je vais bien faire attention à passer au maximum par les variables liées après si l'envirronement n'est pas le même "tant pis" le query s'y trouvera plusieurs fois.

Je vous remercie à tous pour vos précieux conseils.
J'aime bien monter en compétence par le biais des forums :wink:

a+ pour des nouvelles questions.
et encore bravo pour votre réactivité
04/11/2004, 12h28
orafrance

Enfin, ça sert à rien non plus de se focaliser trop là dessus hein ;)
04/11/2004, 12h39
dupin40

C'est bien pour ca que j'ai mis le TAG résolu :D
Je voulais juste me documenter sur ce qu'était le Shared_Pool , je partais de très très bas :oops:
Mais c'est clair tout ca c'est de l'optimisation assez poussé du code pour peu etre pas grand chose.