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 :

Plans d'exécution différents sur 2 schémas identiques


Sujet :

Oracle

  1. #1
    Candidat au Club
    Inscrit en
    Août 2007
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Août 2007
    Messages : 7
    Points : 3
    Points
    3
    Par défaut Plans d'exécution différents sur 2 schémas identiques
    Bonjour,

    J ai 2 vues qui sont identiques sur ma base de dev1 et ma base de dev2.
    Meme indexes sur les tables associees etc...

    Quand j execute mon SELECT sur la vue, ben les plans d executions sont totalement differents.
    dev1: cost de 200
    dev2: cost de 1 350 000

    J ai du rajouter des hints sur dev2 pour obtenir un plan d executions semblable au comportement de dev1. Ouf!

    Pourquoi ce comportement ?
    Comment reduire les risques d avoir des plans d executions differents sur mes environnement ? je ne souhaites pas avoir de nouveau ce genre de surprise lors que la requete sera execute sur un nouvel environnement.

    Merci d avance a tous pour la reponse

  2. #2
    Membre éclairé Avatar de philcero
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Septembre 2007
    Messages
    528
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2007
    Messages : 528
    Points : 773
    Points
    773
    Par défaut
    Afin d'avoir le même comportement entre deux schémas il te faut :

    1. Les mêmes objets (tables, définition des colonnes des tables, indexs).
    2. Les mêmes contenus.
    3. Avoir lancé le calcul des statistiques sur tous les objets impactés.
    4. Avoir le même noyau oracle (Version suffira).

    Généralement ce genre de comportement provient du fait que les statistiques ne sont pas les mêmes entre les deux bases et comme l'optimizer s'appuie dessus...
    Philippe CEROU,

    Architecte Systèmes & Bases de données.

  3. #3
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Et aussi peut-être avoir les même paramètres d'instance pour les paramètres liés à l'optimiseur
    Normalement dans la majorité des cas avec des stats à jour et des indexes bien chosisis (si besoin d'indexes), les hints ne sont pas utiles
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  4. #4
    Candidat au Club
    Inscrit en
    Août 2007
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Août 2007
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    en gros, si la volumetrie des tables impactees est differente entre mes environnements mais que les objets sont identiques, il se peut quand meme alors que les plan d execution different ?

    Ca me parait quand meme impressionant d avoir un tel ecart entre mes costs

  5. #5
    Membre éclairé Avatar de philcero
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Septembre 2007
    Messages
    528
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2007
    Messages : 528
    Points : 773
    Points
    773
    Par défaut
    Tout à fait, l'optimizer va faire des approches statistiques sur tes objets afin de voir quel chemin va aller plus vite.

    Si les volumétries sont différentes il est fort possible que la répartition logique des liens entre tes tables change considérablement de forme d'où un plan totalement différent.

    Si ton problème t'impose d'avoir les même plans d'exécution tu peux calculer tes stats sur la base primaire, les exporter et les importer dans la secondaire et là l'optimizer n'y verra que du feu.
    Philippe CEROU,

    Architecte Systèmes & Bases de données.

  6. #6
    Candidat au Club
    Inscrit en
    Août 2007
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Août 2007
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    Ouais, ca me parait une bonne idee !

    Pour ma part j essayais de hint la requete sur mon 2eme environnement pour forcer d avoir le meme plan d execution que ma base primaire.. C etait ptete pas un bon choix

  7. #7
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Les hints ne sont à utiliser qu'en dernier recours, généralement le problème est ailleurs (modèle non optimisé ou stats pas à jour)
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  8. #8
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    la base peut avoir des paramètres différents, des stats pas calculées de la même manière, pas la même machine dont stats système différentes, etc...

    On connait même pas la version de la base

  9. #9
    Candidat au Club
    Inscrit en
    Août 2007
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Août 2007
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    Merci beaucoup pour les infos.

    Aujourd'hui j'ai fait de nouveaux tests et j'ai remarqué des temps de réponses différentes suivant la methode ou je calcule les statistiques des tables impliquées dans ma vue.

    J'ai des meilleurs temps lors que je fais un compute statistics que un estimate à 20.

    Pour infos, je suis en 9.2.0.6

    Merci

  10. #10
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    C'est surtout les plans d'exécutions qu'il faut comparer pour être sûr
    Les temps d'exécution peuvent être différents en fonction des ressources des machines, indépendemment d'Oracle
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  11. #11
    Membre du Club Avatar de lmartin
    Inscrit en
    Avril 2008
    Messages
    61
    Détails du profil
    Informations forums :
    Inscription : Avril 2008
    Messages : 61
    Points : 68
    Points
    68
    Par défaut
    Pour tes stats utilise le package DBMS_STATS.
    C'est effectivement mieux de faire un compute qu'un estimate, puisque l'estimate n'est qu'un échantillon des données que tu généralise.
    Avec le package DBMS_STATS tu peux calculer les histogrammes et gagner en perf dans certains cas.

  12. #12
    Membre confirmé Avatar de miloux32
    Profil pro
    Inscrit en
    Juillet 2003
    Messages
    545
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2003
    Messages : 545
    Points : 565
    Points
    565
    Par défaut
    Citation Envoyé par scheu Voir le message
    Les hints ne sont à utiliser qu'en dernier recours, généralement le problème est ailleurs (modèle non optimisé ou stats pas à jour)
    Ou tout simplement que lorsqu'on connait le fonctionnel de la base ...

    Exemple :
    Une table avec des millions de lignes , un champ statut qui vaut "En cours", "OK", "KO" ( pour simplifier je donne des noms et pas des valeurs numériques associés)

    La répartition sur ce champs est telle que seuls 1000 enregistrements sont "en cours".
    Pour oracle, un index sur ce champs est pas fiable car pas discriminant ( faire une recherche sur Ok ou KO prend du temps ) or dans le cas d'un "En cours" c'est pertinent comem index
    C'est pas parce que ca marche que c'est bon!!
    Pensez au bouton "Résolu"
    Je ne réponds pas en privé aux questions

Discussions similaires

  1. [10g] Plan d'exécution différent IN ou NOT IN
    Par ldiaz dans le forum SQL
    Réponses: 44
    Dernier message: 23/04/2013, 10h40
  2. Réponses: 10
    Dernier message: 10/07/2012, 21h47
  3. Plans d'exécutions différents suivant la source
    Par jmerigea dans le forum Administration
    Réponses: 11
    Dernier message: 10/07/2009, 22h41
  4. Réponses: 12
    Dernier message: 22/06/2006, 11h26
  5. [MySQL] Résultat de requête différent sur 2 serveurs identiques
    Par schlitters dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 17/12/2005, 01h24

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