Afficher un message
Vieux 02/10/2007, 20h55   #2
pifor
Expert Confirmé
 
Inscription : février 2006
Messages : 3 435
Détails du profil
Informations forums :
Inscription : février 2006
Messages : 3 435
Points : 3 477
Points : 3 477
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/.
__________________
P. Forstmann

AskTom Forums OTN doc 8, 9, 10 et 11
pifor est déconnecté   Envoyer un message privé Réponse avec citation 00