des plans identiques mais des consommations differentes

[kervoaz]

Bonjour,

Sur une meme base, meme environnement j'execute 2 requêtes similaires hormis pour une clause where supplementaire(and x in ('6','x')). Les plans d'exécution sont les mêmes et pourtant les buffer gets et les IO explose lorsque je rajoute le AND(40x).
Je suppose que c'est de la lecture physique qui explique cette différence mais je ne sais absolument pas l'interpreter, la comprendre.

Avez vous une idée?

Merci

[pifor]

Je profite de votre question pour traduire le message suivant http://forums.oracle.com/forums/thre...01834&tstart=0 écrit par Rob van Wijk sur un forum OTN.

Que faire quand votre requête est trop lente ?

D'abord, il faut vous poser la question pourquoi elle est lente. Quelle est la vraie cause du problème. Si le pourquoi est inconnu, suggérer de réécrire la requête, ou d'utiliser un hint, ou de la paralléliser etc. n'est pas très productif. Parfois vous pouvez avoir de la chance. Mais même dans ce cas là, vous devez comprendre que si le problème semble « résolu » vous ne savez pas pourquoi et rien ne garantit que le problème ne réapparaisse pas le lendemain. En conséquence, la première étape est toujours de rechercher la racine du problème.

Vous avez entre autre les outils suivants à votre disposition:

• dbms_profiler
• explain plan
• la trace SQL / tkprof
• statspack

Utilisez dbms_profiler si vous voulez connaître les temps d'exécution du code PL/SQL. Statspack est un must si vous êtes DBA et si vous voulez savoir ce qui se passe au niveau de l'instance. Pour une requête individuelle, explain plan et la trace SQL sont les meilleurs outils.

Explain plan

Il faut taper dans SQL*Plus:

Code :

1
2
EXPLAIN plan FOR <votre requête>;
SELECT * FROM TABLE(dbms_xplan.display);

Si vous avez des messages d'erreur (table inexistante ou vieille version de plan_table), assurez-vous d'exécuter le script utlxplan.sql.
Le script affiche le plan d'exécution de la requête compilée par l'optimiseur. Il donne les éléments nécessaires pour comprendre pourquoi l'optimiseur a choisi un chemin d'accés donné.

Trace SQL/tkprof

Pour ceci, il faut taper dans SQL*Plus:

Code :

1
2
3
ALTER session SET sql_trace=true;
<votre requête SQL>
disconnect

Le disconnect est important car il ferme les curseurs et génére les «row source operation »
Identifier votre fichier trace dans le répertoire sur le serveur désigné par le paramètre d'initialisation de l'instance user_dump_dest.
Exécuter:

Code :

tkprof <fichier trace> a.txt sys=no sort=prsela exela fchela

Le fichier a.txt donne des informations importantes sur ce qui s'est vraiment passé: pas des prévisions mais la vérité.

En comparant le résultat de l'explain plan avec le résultat de tkprof, vous êtes capable d'identifier les différents problèmes.

Avant de se précipiter sur des solutions possibles, il faut toujours donner avec votre question en utilisant les balises de formatage pour faciliter la lecture:

• le résultat de l'explain plan
• le résultat de tkprof
• le code de création de la table et des index
• la façon dont vous calculez les statistiques sur la table et les index
• et la version d'Oracle utilisée !

Voir aussi en détail le tutoriel: http://oracle.developpez.com/guide/tuning/tkprof/.