Discussion :

[genio]

Voilà...
J'ai migré une base existante, d'UNIX (Oracleve 8.1.7) vers NT (Oracle 9.2.1.0)... OK !

J'envoie une requette 'SELECT' :
L'une tourne sur un UNIX en Oracle 8.1.7, et met 0,01 seconde à donner un résultat ...
Et l'autre sur NT en 9.2.1.0... met 3 minutes avant de donner un résultat ...

Le contenu des tables est rigouresement identique... les rebuilt et analyse des index et clés primaires ont été effectués dans les deux bases !

Qu'est-ce que j'ai bien pu ommettre dans le paramètrage de ma base 9i, pour qu'il y ait une si énorme différence ?

Questions : Quel est l'utilité des DB_CACHE_SIZE, DB_KEEP_CACH_SIZE, et DB_RECYCLE_CACHE_SIZE ?

[Jaouad]

Bonjour ,

Pourriez vous éditer le titre afin de le rendre plus clair

Que donnent les plan d'éxècutions ?

DB_CACHE_SIZE: Taille du cache de données
DB_KEEP_CACH_SIZE: Taille du cache pour les objet qui sont Keeper ou eépinglés
DB_RECYCLE_CACHE_SIZE : Taille du cache pour les objets qui sont dans le pool recycle

Les deux derniers sont optionnells , le premier s'il n'est pas paramétré , Oracle en 9i reprend la fameuse formule : DB_BLOCK_BUFFER * DB_BLOCK_SIZE

Jaouad

[genio]

Ja vais tenter d'être plus clair ...
J'ai un select du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT toto,tata
FROM TB1 (319 lignes)
         TB2 (37000 lignes)
         TB2 (702 000 lignes) 
       WHERE TB2.DOSSIER =  TB3.DOSSIER
      AND       TB2.NOBIS =     TB3.NOBIS
      AND TB2.variable ='SODEM'...

là, sur UNIX ou NT la réponse est très rapide... C'est OK car les index sont utilisés de la même façon !

quand j'effectue la même requette avec un 'OR' en plus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT toto,tata
FROM TB1 (319 lignes)
         TB2 (37000 lignes)
         TB2 (702 000 lignes) 
       WHERE TB2.DOSSIER =  TB3.DOSSIER
      AND       TB2.NOBIS =     TB3.NOBIS
      AND (TB2.variable ='SODEM' or [b]TB2.variable = 'SODER'[/b])

Sur Unix, c'est hyper rapide... sur NT la requette dure 3 minutes... l'enfer !

J'ai effectué des AUTOTRACE sur UNIX, et voila ce que ça donne...

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=9057 Card=88255 Bytes=6883890)
1 0 NESTED LOOPS (Cost=9057 Card=88255 Bytes=6883890)
2 1 HASH JOIN (Cost=77 Card=4490 Bytes=206540)
3 2 TABLE ACCESS (FULL) OF 'TB1' (Cost=1 Card=319 Bytes =4785)
4 2 TABLE ACCESS (FULL) OF 'TB2' (Cost=66 Card=4490 Bytes=139190)
5 1 TABLE ACCESS (BY INDEX ROWID) OF 'TB3' (Cost=2 Card=706665 Bytes=22613280)
6 5 INDEX (UNIQUE SCAN) OF 'PK_TB2' (cle primaire de TB2)(UNIQUE) (Cost=1 Card=706665)

Statistics
----------------------------------------------------------
0 recursive calls
14 db block gets
1165 consistent gets
911 physical reads
0 redo size
2098 bytes sent via SQL*Net to client
284 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
9 sorts (memory)
0 sorts (disk)
20 rows processed

ça fonctionne correctement... en 0.01 seconde

Sur NT... la catastrophe...

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=8070 Card=87749 Bytes=6844422)
1 0 HASH JOIN (Cost=8070 Card=87749 Bytes=6844422)
2 1 TABLE ACCESS (FULL) OF 'TB1' (Cost=2 Card=319 Bytes=4785)
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'TB2' (Cost=8061,83547349652 Card=1 Bytes=31)
4 3 NESTED LOOPS (Cost=8061,83547349652 Card=87749 Bytes=5528187)
5 4 TABLE ACCESS (FULL) OF 'TB3' (Cost=888 Card=701988 Bytes=22463616)

6 4 BITMAP CONVERSION (TO ROWIDS)
7 6 BITMAP AND
8 7 BITMAP CONVERSION (FROM ROWIDS)
9 8 INDEX (RANGE SCAN) OF 'TPK_TB2 (cle primaire de TB2) (UNIQUE)
10 7 BITMAP CONVERSION (FROM ROWIDS)
11 10 INDEX (RANGE SCAN) OF 'IDX1_MOUVEMENT' (NON-UNIQUE) (Cost=43 Card=8)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
0 bytes sent via SQL*Net to client
0 bytes received via SQL*Net from client
0 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
5 rows processed

En fait, quand on rajoute le 'OR', il ne prends pas l'index de TB3 et fait un acces FULL...
Comment lui faire prendre l'index de la table la + volumineuse ?
Cela ne doit pas être facile pour vous de voir le problème, mais peut-être avez-vous une idée car je désespère !

Merci de m'avoir lu !

[orafrance]

[ducho]

bonjour,

je crois que dans certains cas, il faut préciser l' optimiseur d' oracle8 .
je ne suis pas sur que ce soit un bug ...

peux-tu passer en 9.2.0.6 sur w2k ?

cdlt

[genio]

Quel genre de précision ? Où plutôt, comment spécifier l'optimiseur d'Oracle ?
J'ai effectué les DBMS_STATS sur les tables et les index, et c'est toujours pareil...

[sebduth]

Avec un UNION au lieu du OR, ça devrait aller mieux jpense...

[genio]

En effet, ça va beaucoup mieux... le UNION se comporte comme un chef ! Il rends une réponse en 3/4 de miettes de secondes... (Alors que le 'IN' est aussi long que le 'OR'... voire plus !)
C'est bizarre les optimiseurs non ? Je crois que mes utilisateurs devront se contenter de cette 'solution', parce que ça fait 2 jours que je galère...

En tout cas je te remercie...

[sebduth]

En effet, ça va beaucoup mieux... le UNION se comporte comme un chef ! Il rends une réponse en 3/4 de miettes de secondes... (Alors que le 'IN' est aussi long que le 'OR'... voire plus !)
C'est bizarre les optimiseurs non ? Je crois que mes utilisateurs devront se contenter de cette 'solution', parce que ça fait 2 jours que je galère...

En tout cas je te remercie...

L'UNION s'imposait vu les temps que tu proposais !!

Pour les IN, c'est très efficace pourtant quand la liste est courte, donc je suis assez surpris de ton résultat. Peut-être qu'en fait ça se comporte comme un OR, ça ne serait pas illogique après tout...