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

SQL Oracle Discussion :

Incompréhension d'un plan d'éxécution


Sujet :

SQL Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre du Club
    Profil pro
    Étudiant
    Inscrit en
    Mars 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mars 2008
    Messages : 6
    Par défaut Incompréhension d'un plan d'éxécution
    Bonjour, mon titre n'est pas très explicite j'avoue.
    J'ai en fait un problème de compréhension quant à l'utilisation ou non d'un index par oracle.
    Voici ma requête:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
      select *
      from ANNONCE this_ 
      inner join LIGNE_COMMANDE lc1_ on this_.NUM_ANN=lc1_.NUM_ANN
      where lower(lc1_.NOM) like '%cora%' order by this_.NUM_ANN desc
    Ici oracle fait un full scan, à cause du lower() et du like '%cora%'.
    Avec cette requête:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
      select *
      from ANNONCE this_ 
      inner join LIGNE_COMMANDE lc1_ on this_.NUM_ANN=lc1_.NUM_ANN
      where lc1_.NOM like 'cora%' order by this_.NUM_ANN desc
    Oracle utilise les index, là aussi je comprends pourquoi.
    Maintenant cette requête:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    select * from 
    ( 
      select *
      from ANNONCE this_ 
      inner join LIGNE_COMMANDE lc1_ on this_.NUM_ANN=lc1_.NUM_ANN
      where lower(lc1_.NOM) like '%cora%' order by this_.NUM_ANN desc 
    ) 
    where rownum <= 20
    Oracle utilise les index..et j'avoue ne pas savoir pourquoi, logiquement à cause du lower() et du '%cora%' il devrait toujours utiliser un full scan.

    Ça risque de vous paraître trivial dans ce cas merci d'éclairer ma lanterne

  2. #2
    Membre Expert Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Par défaut
    Si ton index est sur (lc1_.NOM), Oracle ne peut pas l'utiliser si ta requête porte sur lower(lc1_.NOM). Il faudrait utiliser un index fonctionnel sur lower(lc1_.NOM) pour éviter le full scan
    Par contre pour le '%cora%' l'index ne peut pas être utilisé, il faut que ce soit like 'cora%' (éviter le % en début de chaîne)
    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/

  3. #3
    Membre du Club
    Profil pro
    Étudiant
    Inscrit en
    Mars 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mars 2008
    Messages : 6
    Par défaut
    Oui là dessus on est d'accord.
    En fait je pense que je comprends mal le plan d'exécution.
    Avec ma dernière requête, les index utilisés ne concernent pas NOM, mais sont la PK de la table ANNONCE, et l'index de NUM_ANN sur la ligne de commande.

    J'ai mis en attachement le PEP (une image, je sais pas comment le copier via sqldeveloper), et j'arrive pas à comprendre comment oracle peut ne PAS faire de full scan quand on lui donne un like '%xxx%' ou un lower.

    Ah question subsidiaire (j'ai l'intuition que c'est lié..), quelle est la différence entre ACCESS PREDICATES et FILTER PREDICATES ?
    Images attachées Images attachées  

  4. #4
    Expert confirmé Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Par défaut
    Citation Envoyé par sphax.wd Voir le message
    ...
    Ah question subsidiaire (j'ai l'intuition que c'est lié..), quelle est la différence entre ACCESS PREDICATES et FILTER PREDICATES ?
    19.9 PLAN_TABLE Columns
    ACCESS_PREDICATES
    VARCHAR2(4000)
    Predicates used to locate rows in an access structure. For example, start or stop predicates for an index range scan.

    FILTER_PREDICATES
    VARCHAR2(4000)
    Predicates used to filter rows before producing them.

Discussions similaires

  1. [2008R2] Question sur un plan d'éxécution
    Par KyoshiroKensei dans le forum MS SQL Server
    Réponses: 11
    Dernier message: 20/08/2014, 12h43
  2. Pourquoi ce plan d'éxécution
    Par dehorter olivier dans le forum SQL
    Réponses: 5
    Dernier message: 23/05/2013, 09h51
  3. Analyse de plans d'éxécution
    Par floriann dans le forum Administration
    Réponses: 5
    Dernier message: 20/03/2013, 17h09
  4. Plan d'éxécution sur vue matérialisée
    Par startout dans le forum SQL
    Réponses: 4
    Dernier message: 16/12/2010, 09h45
  5. [TSQL]Imposé un plan d'éxécution ?
    Par arona dans le forum Sybase
    Réponses: 4
    Dernier message: 22/04/2007, 01h08

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