IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Oracle Discussion :

des plans identiques mais des consommations differentes


Sujet :

Oracle

  1. #1
    Membre habitué
    Profil pro
    Inscrit en
    Février 2006
    Messages
    139
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Février 2006
    Messages : 139
    Points : 152
    Points
    152
    Par défaut des plans identiques mais des consommations differentes
    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

  2. #2
    Membre expert

    Profil pro
    Inscrit en
    Février 2006
    Messages
    3 437
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 3 437
    Points : 3 597
    Points
    3 597
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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/.

Discussions similaires

  1. [Débutant] Des IF, des IF, oui mais des AND aussi !
    Par Shennong dans le forum VB.NET
    Réponses: 6
    Dernier message: 11/10/2014, 16h12
  2. Réponses: 9
    Dernier message: 20/10/2010, 11h57
  3. Des dates, des dates oui mais des Panzanis
    Par bonuxis dans le forum Servlets/JSP
    Réponses: 7
    Dernier message: 29/07/2009, 18h27
  4. Rassembler des données identiques issues des champs différents
    Par Wakatanka dans le forum Requêtes et SQL.
    Réponses: 3
    Dernier message: 09/12/2008, 18h31
  5. POST : champs avec des noms identiques ou des IDs ?
    Par Luke58 dans le forum Langage
    Réponses: 1
    Dernier message: 24/05/2007, 12h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo