Discussion :

[genio]

Bonjour à tous...

Je vous joins un document où j'ai effectué deux tkprofs sur 1 select Ordered. Ok

Ce select tourne sur des caisses différentes...

Le traitement de la caisseA s'exécute en 2 minutes, celui de la caisseB en 1 heure...

CaisseA (plus grosse table mpliquée dans le select=> 30 000 000 de ligne)
CaisseB (plus grosse table mpliquée dans le select=> 50 000 000 de ligne)

Les chemins d'accès sont identiques car 'SELECT ORDERED' => Ok
Les stats sont à jour sur les 2 caisses => OK

Il y a une grosse différence entre le Fetch de la caisseA (1 fetch) et celui de la caisseB (21850 fetchs).
La caisseB a deux fois plus de mémoire (SGA, SHARED-POOL, JAVA_POOL etc...) que la caisseA => OK

Pourquoi d'après vous, la différence d'exécution entre les fetch est-elle aussi importante... et qu'est-ce qui pourrait faire qu'une database 1 fois 1/2 plus grosse qu'une autre (30 000 000 contre 50 000 000) puisse générer des temps d'attente aussi décalés (de 2 minutes à 1 heure) étant donné que les chemin d'accès sont identiques...
Vous pourrez voir aussi que les volumétries triées ne sont pas les mêmes entre les deux caisses... et c'est peut-être pour cela que le temps d'exécution passe de 2 minutes à 1 heure, mais j'ai doublé les zones mémoires de la caisse à 50 000 000 de ligne et cela n'a rien changé !
Comment pouvez-vous expliquer ça ?
A part réécrire le select, verriez-vous une autre piste pour optimiser...

Merci d'avance pour vos réponses...

[PpPool]

peux tu nous fournir la requete incriminée ?

c'est au niveau disque à mon avis qu'il y a une différence entre les 2 serveurs. dans ton explain il va bien chercher sur le disk et non en mémoire.
As tu les configs à nous donner ?

Si tu relances la même requete obtients tu les mêmes explain plan.
As tu bien binder tes requetes ?

de plus dans ton explain tu as des produits cartésiens pour plusieurs jointures. C'est souvent malheureusement le signe de jointures oubliées, ou de requetes imbriquées.

[orafrance]

D'abord, 1.5 fois le volume signifie pas 1.5 fois plus de temps.

Ensuite, il semblerait que les stats ne sont pas ou mal calculées dans le 1er cas ou alors que la requête ne retourne aucun résultat (rows=0). Donc, là il y a un truc louche

C'est quelle version de OA et Oracle ? Pourquoi le ORDERED ?

Et non, les plans ne sont pas les mêmes :

0 TABLE ACCESS FULL FND_FLEX_VALUES_TL
0 FILTER
0 HASH JOIN
0 TABLE ACCESS FULL FND_FLEX_VALUES
0 MERGE JOIN CARTESIAN
0 HASH JOIN
0 TABLE ACCESS FULL FND_FLEX_VALUES
0 MERGE JOIN CARTESIAN
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 MERGE JOIN CARTESIAN
0 TABLE ACCESS BY INDEX ROWID GL_CODE_COMBINATIONS
0 INDEX RANGE SCAN GL_CODE_COMBINATIONS_N99 (object id 244972)
0 BUFFER SORT
0 TABLE ACCESS BY INDEX ROWID GL_PERIOD_STATUSES
0 INDEX RANGE SCAN GL_PERIOD_STATUSES_U2 (object id 74977)
0 TABLE ACCESS BY INDEX ROWID GL_JE_LINES
0 INDEX RANGE SCAN GL_JE_LINES_N1 (object id 34055)
0 TABLE ACCESS BY INDEX ROWID GL_JE_HEADERS
0 INDEX UNIQUE SCAN GL_JE_HEADERS_U1 (object id 34017)
0 INDEX UNIQUE SCAN GL_JE_SOURCES_TL_U1 (object id 74988)
0 TABLE ACCESS BY INDEX ROWID FND_CURRENCIES
0 INDEX UNIQUE SCAN FND_CURRENCIES_U1 (object id 32944)
0 BUFFER SORT
0 TABLE ACCESS FULL FND_FLEX_VALUES_TL
0 BUFFER SORT
0 TABLE ACCESS FULL FND_FLEX_VALUES_TL

29181 TABLE ACCESS FULL FND_FLEX_VALUES_TL
0 FILTER
0 HASH JOIN
0 TABLE ACCESS FULL FND_FLEX_VALUES
0 MERGE JOIN CARTESIAN
0 NESTED LOOPS
0 MERGE JOIN CARTESIAN
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 MERGE JOIN CARTESIAN
0 TABLE ACCESS BY INDEX ROWID GL_CODE_COMBINATIONS
0 INDEX RANGE SCAN GL_CODE_COMBINATIONS_N99 (object id 497011)
0 BUFFER SORT
0 TABLE ACCESS BY INDEX ROWID GL_PERIOD_STATUSES
0 INDEX RANGE SCAN GL_PERIOD_STATUSES_U2 (object id 74977)
0 TABLE ACCESS BY INDEX ROWID GL_JE_LINES
0 INDEX RANGE SCAN GL_JE_LINES_N1 (object id 34055)
0 TABLE ACCESS BY INDEX ROWID GL_JE_HEADERS
0 INDEX UNIQUE SCAN GL_JE_HEADERS_U1 (object id 34017)
0 INDEX UNIQUE SCAN GL_JE_SOURCES_TL_U1 (object id 74988)
0 TABLE ACCESS BY INDEX ROWID FND_CURRENCIES
0 INDEX UNIQUE SCAN FND_CURRENCIES_U1 (object id 32944)
0 BUFFER SORT
0 TABLE ACCESS FULL FND_FLEX_VALUES_TL
0 TABLE ACCESS BY INDEX ROWID FND_FLEX_VALUES
0 INDEX UNIQUE SCAN FND_FLEX_VALUES_U1 (object id 33502)
0 BUFFER SORT
0 TABLE ACCESS FULL FND_FLEX_VALUES_TL

dans le 2eme cas tu remplaces un FTS de FND_FLEX_VALUES par un accès par ROWID !

J'ai l'impression qu'il manque des jointures... il faut éviter les raccourcis du genre ignorer la ligne en rouge même si fonctionnellement elle n'apporte rien:

t1.a = t2.a
and t1.a = t3.a
and t2.c = t3.c

[genio]

Merci pour vos réponses :
Pour PpPool, la requête est dans le document envoyé, en denière page...
Pour Orafrance : Les stats de la 1er caisse (rows=0) ont été appliquées, effectivement, il y a un certain temps... en fait nous avons une politique d'application des mêmes stats sur toutes nos caisses... et effectivement, les stats de la caisse qui ne fonctionne pas, ont été rafraîchies hier (mais avec les anciennes stats, cela ne fonctionne pas non plus... donc nous cherchons d'autres pistes (le ORDERED en fait partie) !)
1°) je croyais que les temps 'cpu' et 'elapsed' etaient exprimés en secondes : comment expliquer le '39605400.00' de la CPU et le '38838288.45' de l'elapsed...
2°) comment expliquer que le temps CPU soit > au temps elapsed ?
3°) Le nombre de row est-il celui qui est lu dans tout le traitement ou bien lu pour un seul select ?
et 4°) Query=180367 et disk=1366 me semblent être de bons chiffres, alors pourquoi ce traitement est-il si long...

Merci pour vos réponses

[orafrance]

4) simplement les disques qui sont moins performant ou plus de contentions sur les I/O... qu'en pense statspack ?