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 :

Problème de performance sur SELECT avec jointures


Sujet :

SQL Oracle

  1. #21
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Décembre 2011
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2011
    Messages : 15
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par mnitu Voir le message
    C'est écrit de le début 4.173.000 /
    Peut être qu’en changeant de stratégie (= de requête) on pourrait gagner quelque chose de plus.
    Voici le plan d'execution pour la même requete avec un type de document différent, beaucoup moins représenté dans la table Document :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    PLAN_TABLE_OUTPUT
    SQL_ID  2r597zddqdwd9, child number 0
    -------------------------------------
    SELECT         *      FROM         ( SELECT             DISTINCT pensionne0_.ID_PENSIONNE AS ID1_5_,             pensionne0_.BLOC_NOTE AS BLOC2_5_,             
    pensionne0_.DATE_DECES AS DATE3_5_,             pensionne0_.DATE_NAISS AS DATE4_5_,             pensionne0_.ID_PENSIONNE_TMP AS ID5_5_,             
    pensionne0_.ID_SERVICE AS ID6_5_,             pensionne0_.NOM_MARITAL AS NOM7_5_,             pensionne0_.NOM_PATRONYME AS NOM8_5_,             
    pensionne0_.PRENOMS AS PRENOMS5_          FROM             PENSIONNE pensionne0_          LEFT OUTER JOIN             SOUS_DOSSIER sousdossie1_                 
     ON pensionne0_.ID_PENSIONNE=sousdossie1_.ID_PENSIONNE          LEFT OUTER JOIN             DOCUMENT documentco2_                  ON 
    sousdossie1_.ID_SOUS_DOSSIER=documentco2_.ID_SOUS_DOSSIER          WHERE             pensionne0_.ID_SERVICE='059000'              AND 
    documentco2_.ID_TYPE_DOCUMENT='150'          ORDER BY             pensionne0_.ID_PENSIONNE )      WHERE         rownum <
     
    Plan hash value: 778032787
     
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                         | Name              | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Used-Mem | Used-Tmp|
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    |*  1 |  COUNT STOPKEY                    |                   |      1 |        |    100 |00:00:19.02 |     179K|    177K|    403 |       |       |          |         |
    |   2 |   VIEW                            |                   |      1 |   8535 |    100 |00:00:19.02 |     179K|    177K|    403 |       |       |          |         |
    |*  3 |    SORT ORDER BY STOPKEY          |                   |      1 |   8535 |    100 |00:00:19.02 |     179K|    177K|    403 | 22528 | 22528 |20480  (0)|         |
    |   4 |     SORT UNIQUE                   |                   |      1 |   8535 |  13793 |00:00:18.99 |     179K|    177K|    403 |  2210K|   780K| 1964K (0)|         |
    |*  5 |      HASH JOIN                    |                   |      1 |   8535 |  17196 |00:00:18.90 |     179K|    177K|    403 |  4740K|  1518K| 7739K (0)|    3072 |
    |*  6 |       HASH JOIN                   |                   |      1 |    116K|    100K|00:00:17.39 |     160K|    158K|      0 |  3861K|  1994K| 6715K (0)|         |
    |   7 |        TABLE ACCESS BY INDEX ROWID| DOCUMENT          |      1 |    116K|    101K|00:00:04.46 |   72317 |  71902 |      0 |       |       |          |         |
    |*  8 |         INDEX RANGE SCAN          | IN_DOC_TYPEDOC    |      1 |    116K|    101K|00:00:03.25 |     638 |    638 |      0 |       |       |          |         |
    |   9 |        TABLE ACCESS FULL          | SOUS_DOSSIER      |      1 |   8345K|   8345K|00:00:00.01 |   88371 |  86837 |      0 |       |       |          |         |
    |  10 |       TABLE ACCESS BY INDEX ROWID | PENSIONNE         |      1 |    345K|    360K|00:00:00.72 |   18734 |  18587 |      0 |       |       |          |         |
    |* 11 |        INDEX RANGE SCAN           | IN_PENSIONNE_SERV |      1 |    345K|    360K|00:00:00.01 |    2403 |   2403 |      0 |       |       |          |         |
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
     
    Predicate Information (identified by operation id):
    ---------------------------------------------------
     
       1 - filter(ROWNUM<=100)
       3 - filter(ROWNUM<=100)
       5 - access("PENSIONNE0_"."ID_PENSIONNE"="SOUSDOSSIE1_"."ID_PENSIONNE")
       6 - access("DOCUMENTCO2_"."ID_SOUS_DOSSIER"="SOUSDOSSIE1_"."ID_SOUS_DOSSIER")
       8 - access("DOCUMENTCO2_"."ID_TYPE_DOCUMENT"=150)
      11 - access("PENSIONNE0_"."ID_SERVICE"='059000')
    Le nombre d'occurence de la valeur id_type_document=150 dans la table document est de :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     SELECT count(*), count(case Id_TYPE_DOCument when 150 then 1 end)  FROM document ==> 101073
    Nous pourrions envisager de demander à l'utilisateur d'affiner ses critères de recherches dans le cas ou sa demande renverrait plus de 100 réponses.

    La question est : Comment savoir à l'avance combien de lignes la requete va renvoyer ?
    Faire un count coute quasiment aussi cher que ramener les lignes.

    Voyez vous un un moyen de résoudre cette problématique ?

    Par exemple, est il possible d'interroger dans un programme Java le plan d’exécution d'une requête ou bien les données statistiques ?

  2. #22
    Membre éclairé
    Profil pro
    Inscrit en
    Février 2010
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 412
    Points : 807
    Points
    807
    Par défaut
    Perso, je tenterai bien un index sur documents(id_type_document,id_sous_dossier) au lieu de l'index sur documents(id_type_document).

    Pour le requetes ou le numero de type_document est peu present, on aurait le meme effet. Et pour les requetes genre celle ou vous avec id_type_document=10 qui renvoie tout plein de resultats, ca permettrait peut-etre d'utiliser l'index, en un "fast full-index scan" vu que toutes les infos seraient dedans.
    Parce que la concretement, il peut pas l'utiliser pour id_type_document=10.

    Edit:Et d'ailleurs, tant qu'on y est:
    SOUS_DOSSIER(ID_PENSIONNE,ID_SOUS_DOSSIER )Mais pour l'ordre des colonnes, la je suis pas tres convaincu. Mais bon, visiblement c'est pas ca qui prends du temps, ce qui est marrant d'ailleurs...

  3. #23
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Décembre 2011
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2011
    Messages : 15
    Points : 4
    Points
    4
    Par défaut
    Merci pour cette piste.
    Cependant, j'ai créé l'index documents(id_type_document,id_sous_dossier), mais cela ne change rien au plan d’exécution : ce nouvel index n'est pas utilisé.

  4. #24
    Membre expérimenté

    Homme Profil pro
    Inscrit en
    Mars 2010
    Messages
    536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 536
    Points : 1 359
    Points
    1 359
    Par défaut
    Citation Envoyé par ORA-007 Voir le message
    Bonjour,

    PS2 : Quelqu'un sait il le seuil à partir duquel Oracle fait un FULL SCAN et quel parametre le régit ?
    Vous avez votre réponse dans l'article suivant de jonathan Lewis

    http://jonathanlewis.wordpress.com/category/philosophy/

    Que je viens de traduire à l'instant

    Traduction

    Si vous exécutez une requête qui est supposée retourner un seul enregistrement à partir d'une très large table, et, vous disposez d'un index approprié sur cette table, vous vous attendrez probablement à ce que l'optimisateur d'Oracle identifie l'index et qu'il l'utilise. Si vous changez votre requête de telle sorte qu'elle renvoi tous les enregistrements de cette table (sans tri) vous vous attendrez probablement à ce que l'optimisateur d'Oracle choisisse un full table scan.

    Ceci conduit à la très simple idée qui est souvent ignorée

    "Quelques fois il suffit juste d'un enregistrement supplémentaire pour passer d'un plan d'exécution utilisant un index à un plan utilisant un full table scan"

    Il existe un point où l'optimisateur change d'un accès indexé à un seul enregistrement vers un accès à toute la table pour tous les enregistrements.

    Si vous êtes assez chanceux et le modèle de l'optimisateur est parfait il n'y aura aucun effet significatif sur la performance, bien sûr. Mais, nous ne sommes pas aussi chanceux que ça, et c'est pour cette raison que les gens finissent par poser la question : 'Comment le plan d'exécution est devenu subitement non performant, il n'y a eu aucun changement .... sauf pour un petit supplément de données?". Tout ce qu'il faut c'est un seul enregistrement (que l'optimisateur reconnait) pour changer d'un plan d'exécution à un autre- et parfois l'optimisateur trouve le mauvais moment pour opérer ce changement.
    Bien Respectueusement
    www.hourim.wordpress.com

    "Ce qui se conçoit bien s'énonce clairement"

  5. #25
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Décembre 2011
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2011
    Messages : 15
    Points : 4
    Points
    4
    Par défaut
    Je reformule ma question : Est il possible dans un programme (java ou autre) de connaitre le nombre de lignes qu'une requête va ramener, mais sans exécuter la requête (ie en se basant sur les statistiques) ?

  6. #26
    Membre expérimenté

    Homme Profil pro
    Inscrit en
    Mars 2010
    Messages
    536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 536
    Points : 1 359
    Points
    1 359
    Par défaut
    Si tant est que cela soit possible, comment être sûr dans ce cas que les statistiques sont à jour????

    Je ne pense pas que ce que vous proposez soit possible. Il faudrait plutôt se concentrer sur l'amélioration de votre requête.

    J'ai une question quand même : Est-ce que le client se plaint de la performance parce qu'il s'est habitué à voir cette requête s'exécuter rapidement ou bien c'est du premier coup qu'il s'est plaint de la performance?
    Bien Respectueusement
    www.hourim.wordpress.com

    "Ce qui se conçoit bien s'énonce clairement"

  7. #27
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Décembre 2011
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2011
    Messages : 15
    Points : 4
    Points
    4
    Par défaut
    Le client est en phase de recette de cette application, et considère comme une anomalie les temps de réponse de ce cas d'utilisation.

    Il accepterait que le système renvoie un message à l'utilisateur lui précisant que le résultat de sa recherche va dépasser les 100 réponses et lui demandant d'affiner ses critères de recherches (sans que la recherche soit effectivement faite).

    En ce qui concerne la validité des statistiques, ne sont elles pas maintenues à jour en permanence par Oracle ?

  8. #28
    Membre expérimenté

    Homme Profil pro
    Inscrit en
    Mars 2010
    Messages
    536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 536
    Points : 1 359
    Points
    1 359
    Par défaut
    Citation Envoyé par mnitu Voir le message
    C'est écrit de le début 4.173.000 /
    Pas d'index parce que c'est un Hash Join.
    Ce n'est certainement pas une nécessité ni une règle que la jointure HASH JOIN se fasse toujours via un FULL TABLE SCAN. Jonathan Lewis dans son livre Cost Based Oracle Fundamentals au Chapitre 12, Hash Join, page 321, parle(par l'exemple) justement de cette pas toujours vraie règle mais néanmoins largement répandue dans le monde Oracle
    Bien Respectueusement
    www.hourim.wordpress.com

    "Ce qui se conçoit bien s'énonce clairement"

  9. #29
    Membre éclairé
    Profil pro
    Inscrit en
    Février 2010
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 412
    Points : 807
    Points
    807
    Par défaut
    Citation Envoyé par Mohamed.Houri Voir le message
    Je ne pense pas que ce que vous proposez soit possible. Il faudrait plutôt se concentrer sur l'amélioration de votre requête.
    AMHA, un truc comme ca peut fonctionner, ca copie juste le fonctionnement de autotrace traceonly. Mais bon, qui dit explain plan, dit erreur possible aussi. Justement avec les statistiques.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    --explain plan set statement_id='toto' for select * from tmp2;
    select cardinality, id,depth, position from plan_table where statement_id='toto' order by id;
     
    create or replace function tmp_func(p_param number) return number is
    begin
       dbms_lock.sleep(0.1);
       return 1;
    end;
    /
    associate statistics with functions tmp_func default selectivity 100;
    drop table tmp2;
    create table tmp2 as select level as n from dual connect by level<=100;
    set timing on;
    --set autotrace on
    --select * from tmp2 where tmp_func(n)=1;
    --Temps: 1000*0.1 = 10s
    --set autotrace off
     
    --set autotrace traceonly
    --select * from tmp2 where tmp_func(n)=1;
    --Temps: 1000*0.1 = 10s
    --set autotrace off
     
     
    explain plan set statement_id='miouf2' for select * from tmp2 where tmp_func(n)=1;
    select cardinality from plan_table where statement_id='miouf2' and id=0;
    Bien entendu, dans ce cas la il faudra soit changer le statement_id, soit faire un tri sur le plan qui vous interesse.

  10. #30
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 814
    Points
    17 814
    Par défaut
    Il faut bien définir votre besoin.
    Si votre seuil d'affichage est de cent lignes, la première requête que je vous ai donné peut répondre rapidement : le calcul du tri avait un certain coût.
    On peut aussi envisager un hint - je ne suis pas certain de l'impact cela dit :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    SELECT /*+ FIRST_ROWS */
           pns.ID_PENSIONNE
         , pns.BLOC_NOTE
         , pns.DATE_DECES
         , pns.DATE_NAISS
         , pns.ID_PENSIONNE_TMP
         , pns.ID_SERVICE
         , pns.NOM_MARITAL
         , pns.NOM_PATRONYME
         , pns.PRENOMS
      FROM PENSIONNE pns  
     WHERE pns.ID_SERVICE = '059000'
       AND EXISTS (SELECT NULL
                     FROM SOUS_DOSSIER sdo
                          INNER JOIN DOCUMENT doc
                            ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER  
                    WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                      AND doc.ID_TYPE_DOCUMENT = 10)
      AND ROWNUM <= 101;
    Si vous atteignez la ligne 101, c'est que vous avez plus de cent lignes et vous pouvez afficher un message adéquat à l'utilisateur.

    En y réfléchissant, même avec le type 150 vous arrivez à 13.000 lignes, il faut repenser votre besoin je pense.

  11. #31
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2 947
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 2 947
    Points : 5 846
    Points
    5 846
    Par défaut
    En soit ça ne me choque pas que la requête puisse ramener dans les 100 000 lignes tant qu'elle est paginée pour ne fetch que 100 lignes.
    Après je ne vois pas pourquoi essayer de conserver la requête très innéficace d'hibernate.
    En effet DISTINCT + LEFT JOIN avec filtre WHERE sur la table en LEFT JOIN (ce qui revient à faire un INNER JOIN...) montre que cette requête ne convient pas du tout.

    Il faut partir de la requête de Waldar (hibernate peux executer des requêtes directement) et regarder son plan.
    Il peut être intéressant de faire une trace level 12 + TKPROF pour voir ce qui se passe car apparemment le FULL SCAN de DOCUMENTS est qu'en même très lent.

    Sinon j'utiliserais bien aussi le hint FIRST_ROWS(N) dans la requête de Waldar (de toute façon ça fournie juste plus d'info à l'optimiseur, ça ne fait donc pas de mal):
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    WITH SR AS
    (
      SELECT /*+ FIRST_ROWS(100) */
             pns.ID_PENSIONNE
           , pns.BLOC_NOTE
           , pns.DATE_DECES
           , pns.DATE_NAISS
           , pns.ID_PENSIONNE_TMP
           , pns.ID_SERVICE
           , pns.NOM_MARITAL
           , pns.NOM_PATRONYME
           , pns.PRENOMS
        FROM PENSIONNE pns  
       WHERE pns.ID_SERVICE = '059000'
         AND EXISTS (SELECT NULL
                       FROM SOUS_DOSSIER sdo
                            INNER JOIN DOCUMENT doc
                              ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER  
                      WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                        AND doc.ID_TYPE_DOCUMENT = 10)
    ORDER BY pns.ID_PENSIONNE ASC
    )
    SELECT ID_PENSIONNE
         , BLOC_NOTE
         , DATE_DECES
         , DATE_NAISS
         , ID_PENSIONNE_TMP
         , ID_SERVICE
         , NOM_MARITAL
         , NOM_PATRONYME
         , PRENOMS
      FROM SR
     WHERE ROWNUM <= 100;
    Après si c'est toujours très lent il est peut être envisageable de s'orienter vers une vue matérialisée qui pourrait réduire le travail à fournir pour la requête.

    Juste un point, il me semble que tu disais que tu étais en recette, le serveur de recette est il ISO future PROD ? notemment concernant les disques.

  12. #32
    Membre émérite Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Points : 2 845
    Points
    2 845
    Par défaut
    Salut,

    Je suis bien d'accord avec toi Waldar. Cela dit ce n'est pas forcément le besoin qui est mal exprimé, ça peut très bien être le modèle ou le "process".

    Finalement, on voit souvent ce genre de problème : ton modèle est totalement normalisé, et tes critères de recherche (sans dépendances) sont éparpillés. T'es obligé de faire une VM comme le suggère Skuat.

    La seule question qui reste c'est : est-il rationnel de faire une recherche sur la possession d'un type de document ? Quel est la fréquence d'une telle recherche ?

    - Si c'est un cas d'exception, 50 secondes ne sont vraiment pas choquantes.
    - Si c'est le quotidien du chargé, il faut faire une VM, et surtout se demander pourquoi on doit sortir en interactif la liste des gens qui ont eu un certain type de document...

    (c'est ma photo)
    Paku, Paku !
    Pour les jeunes incultes : non, je ne suis pas un pokémon...

    Le pacblog : http://pacmann.over-blog.com/

  13. #33
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Décembre 2011
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2011
    Messages : 15
    Points : 4
    Points
    4
    Par défaut
    Un grand merci à tous pour vos réponses pertinentes.
    Je vais tester les différentes solutions/approches proposées et vous ferais un retour.

    Concernant les différentes questions posées :

    Citation Envoyé par skuatamad Voir le message
    Juste un point, il me semble que tu disais que tu étais en recette, le serveur de recette est il ISO future PROD ? notemment concernant les disques.
    Notre serveur de recette est configuré pour être "aussi proche" de la production que possible, on peut donc s'attendre à des performances similaires.

    Citation Envoyé par pacmann Voir le message
    La seule question qui reste c'est : est-il rationnel de faire une recherche sur la possession d'un type de document ? Quel est la fréquence d'une telle recherche ?

    - Si c'est un cas d'exception, 50 secondes ne sont vraiment pas choquantes.
    - Si c'est le quotidien du chargé, il faut faire une VM, et surtout se demander pourquoi on doit sortir en interactif la liste des gens qui ont eu un certain type de document...
    C'est effectivement la question que devra se poser la MOA si l'on ne trouve pas de solution d'optimisation efficace.

  14. #34
    Membre émérite Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Points : 2 845
    Points
    2 845
    Par défaut
    Citation Envoyé par jalaval Voir le message
    C'est effectivement la question que devra se poser la MOA si l'on ne trouve pas de solution d'optimisation efficace.
    Si je peux me permettre, à mon sens, la MOA pourrait (devrait ?) se poser cette question même si on trouve une optimisation.

    A quoi ça sert ? Dans quel contexte ? Est-ce vraiment ce qu'on cherche dans notre process ? Notre process est-il bien design-gné ?
    => Ca a l'air intéressant en tant que MOA, non ?

    (c'est ma photo)
    Paku, Paku !
    Pour les jeunes incultes : non, je ne suis pas un pokémon...

    Le pacblog : http://pacmann.over-blog.com/

  15. #35
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Décembre 2011
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2011
    Messages : 15
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par skuatamad Voir le message
    Il peut être intéressant de faire une trace level 12 + TKPROF pour voir ce qui se passe car apparemment le FULL SCAN de DOCUMENTS est qu'en même très lent.
    Voici le résultat de la trace demandée :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    "jla.txt" 122 lignes, 5099 caractères
     
    TKPROF: Release 10.2.0.3.0 - Production on Mar. Déc. 20 14:24:47 2011
     
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
     
    Trace file: gm2011_ora_1646672.trc
    Sort options: exeela
    ********************************************************************************
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    ********************************************************************************
     
    WITH SR AS
    (
      SELECT
             pns.ID_PENSIONNE
           , pns.BLOC_NOTE
           , pns.DATE_DECES
           , pns.DATE_NAISS
           , pns.ID_PENSIONNE_TMP
           , pns.ID_SERVICE
           , pns.NOM_MARITAL
           , pns.NOM_PATRONYME
           , pns.PRENOMS
        FROM PENSIONNE pns
       WHERE pns.ID_SERVICE = '059000'
         AND EXISTS (SELECT NULL
                       FROM SOUS_DOSSIER sdo
                            INNER JOIN DOCUMENT doc
                              ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER
                      WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                        AND doc.ID_TYPE_DOCUMENT = 10)
    ORDER BY pns.ID_PENSIONNE ASC
    )
    SELECT ID_PENSIONNE
         , BLOC_NOTE
         , DATE_DECES
         , DATE_NAISS
         , ID_PENSIONNE_TMP
         , ID_SERVICE
         , NOM_MARITAL
         , NOM_PATRONYME
         , PRENOMS
      FROM SR
     WHERE ROWNUM <= 100
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        2      0.01       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        3      0.01       0.00          0          0          0           0
     
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 30
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     1        0.02          0.02
      db file sequential read                     48515        0.00          0.31
     
     
     
    ********************************************************************************
     
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        2      0.01       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        3      0.01       0.00          0          0          0           0
     
    Misses in library cache during parse: 1
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       3        0.00          0.00
      SQL*Net message from client                     2        9.88          9.91
      db file sequential read                     48515        0.00          0.31
     
     
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        0      0.00       0.00          0          0          0           0
     
    Misses in library cache during parse: 0
     
        2  user  SQL statements in session.
        0  internal SQL statements in session.
        2  SQL statements in session.
    ********************************************************************************
    Trace file: gm2011_ora_1646672.trc
    Trace file compatibility: 10.01.00
    Sort options: exeela
           1  session in tracefile.
           2  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           2  SQL statements in trace file.
           1  unique SQL statements in trace file.
       48621  lines in trace file.
           0  elapsed seconds in trace file.

  16. #36
    Expert éminent sénior 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
    Points : 11 252
    Points
    11 252
    Par défaut
    Deux parse un execute ce n’est pas bon mais ça c’est une autre histoire.
    Sinon ça va tellement vite sauf que apparemment ça n’a rien ramené (rows = 0).
    Mais, il se peut aussi que la session n'a pas été fermée et que les statististique ne sont pas disponible.

  17. #37
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Décembre 2011
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2011
    Messages : 15
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par mnitu Voir le message
    Deux parse un execute ce n’est pas bon mais ça c’est une autre histoire.
    Sinon ça va tellement vite sauf que apparemment ça n’a rien ramené (rows = 0).
    Mais, il se peut aussi que la session n'a pas été fermée et que les statististique ne sont pas disponible.
    OK voici la trace session fermée (c'est un peu long) :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    221
    222
    223
    224
    225
    226
    227
    228
    229
    230
    231
    232
    233
    234
    235
    236
    237
    238
    239
    240
    241
    242
    243
    244
    245
    246
    247
    248
    249
    250
    251
    252
    253
    254
    255
    256
    257
    258
    259
    260
    261
    262
    263
    264
    265
    266
    267
    268
    269
    270
    271
    272
    273
    274
     
     
    TKPROF: Release 10.2.0.3.0 - Production on Mer. Déc. 21 09:40:25 2011
     
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
     
    Trace file: /u02/admin/GM2011/udump/gm2011_ora_jla.trc
    Sort options: exeela  
    ********************************************************************************
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing 
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    ********************************************************************************
     
    select /*+ rule */ bucket, endpoint, col#, epvalue 
    from
     histgrm$ where obj#=:1 and intcol#=:2 and row#=:3 order by bucket
     
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      0.00       0.00          0          0          0           0
    Execute     97      0.02       0.01          0          0          0           0
    Fetch       97      0.02       0.09         17        395          0        1862
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total      195      0.04       0.11         17        395          0        1862
     
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: RULE
    Parsing user id: SYS   (recursive depth: 1)
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
         20  SORT ORDER BY (cr=4 pr=2 pw=0 time=12030 us)
         20   TABLE ACCESS CLUSTER HISTGRM$ (cr=4 pr=2 pw=0 time=11916 us)
          1    INDEX UNIQUE SCAN I_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=22 us)(object id 252)
     
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                        17        0.00          0.07
    ********************************************************************************
     
    select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, 
      sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, 
      spare1, spare2, avgcln 
    from
     hist_head$ where obj#=:1 and intcol#=:2
     
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      0.00       0.00          0          0          0           0
    Execute     16      0.00       0.00          0          0          0           0
    Fetch       16      0.00       0.01          2         48          0          16
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total       33      0.00       0.02          2         48          0          16
     
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: RULE
    Parsing user id: SYS   (recursive depth: 1)
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          1  TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=3 pr=1 pw=0 time=8853 us)
          1   INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=61 us)(object id 257)
     
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                         2        0.00          0.01
    ********************************************************************************
     
    select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,
      o.dataobj#,o.flags 
    from
     obj$ o where o.obj#=:1
     
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      0.00       0.00          0          0          0           0
    Execute     10      0.01       0.00          0          0          0           0
    Fetch       10      0.00       0.00          0         30          0          10
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total       21      0.01       0.00          0         30          0          10
     
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: CHOOSE
    Parsing user id: SYS   (recursive depth: 1)
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          1  TABLE ACCESS BY INDEX ROWID OBJ$ (cr=3 pr=0 pw=0 time=92 us)
          1   INDEX UNIQUE SCAN I_OBJ1 (cr=2 pr=0 pw=0 time=56 us)(object id 36)
     
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1      119.34        119.34
    ********************************************************************************
     
    begin :id := sys.dbms_transaction.local_transaction_id; end;
     
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           1
    Fetch        0      0.00       0.00          0          0          0           0
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        2      0.00       0.00          0          0          0           1
     
    Misses in library cache during parse: 0
    Optimizer mode: CHOOSE
    Parsing user id: 30  
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        0.02          0.02
    ********************************************************************************
     
    select 'x' 
    from
     dual
     
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.00       0.00          0          0          0           1
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        3      0.00       0.00          0          0          0           1
     
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 30  
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          1  FAST DUAL  (cr=0 pr=0 pw=0 time=5 us)
     
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        0.02          0.02
    ********************************************************************************
     
    WITH SR AS
    (
      SELECT pns.ID_PENSIONNE
           , pns.BLOC_NOTE
           , pns.DATE_DECES
           , pns.DATE_NAISS
           , pns.ID_PENSIONNE_TMP
           , pns.ID_SERVICE
           , pns.NOM_MARITAL
           , pns.NOM_PATRONYME
           , pns.PRENOMS
        FROM PENSIONNE pns  
       WHERE pns.ID_SERVICE = '059000'
         AND EXISTS (SELECT NULL
                       FROM SOUS_DOSSIER sdo
                            INNER JOIN DOCUMENT doc
                              ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER  
                      WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                        AND doc.ID_TYPE_DOCUMENT = 10)
    ORDER BY pns.ID_PENSIONNE ASC
    )
    SELECT ID_PENSIONNE
         , BLOC_NOTE
         , DATE_DECES
         , DATE_NAISS
         , ID_PENSIONNE_TMP
         , ID_SERVICE
         , NOM_MARITAL
         , NOM_PATRONYME
         , PRENOMS
      FROM SR
     WHERE ROWNUM <= 100
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        2      0.02       0.02          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     41.30     244.17     542230    4183975          0         100
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        4     41.32     244.20     542230    4183975          0         100
     
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 30  
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     2       59.49         59.52
      db file sequential read                    542230        0.17        209.16
      SQL*Net more data to client                     5        0.00          0.00
     
     
     
    ********************************************************************************
     
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        4      0.02       0.02          0          0          0           0
    Execute      3      0.00       0.00          0          0          0           1
    Fetch        2     41.30     244.17     542230    4183975          0         101
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        9     41.32     244.20     542230    4183975          0         102
     
    Misses in library cache during parse: 2
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       6        0.00          0.00
      SQL*Net message from client                     6      119.34        179.59
      db file sequential read                    542230        0.17        209.16
      SQL*Net more data to client                     5        0.00          0.00
     
     
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        3      0.00       0.00          0          0          0           0
    Execute    123      0.03       0.02          0          0          0           0
    Fetch      123      0.02       0.10         19        473          0        1888
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total      249      0.05       0.13         19        473          0        1888
     
    Misses in library cache during parse: 3
    Misses in library cache during execute: 3
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                        19        0.00          0.09
     
        4  user  SQL statements in session.
      123  internal SQL statements in session.
      127  SQL statements in session.
    ********************************************************************************
    Trace file: /u02/admin/GM2011/udump/gm2011_ora_jla.trc
    Trace file compatibility: 10.01.00
    Sort options: exeela  
           1  session in tracefile.
           4  user  SQL statements in trace file.
         123  internal SQL statements in trace file.
         127  SQL statements in trace file.
           6  unique SQL statements in trace file.
      545371  lines in trace file.
         303  elapsed seconds in trace file.

  18. #38
    Expert éminent sénior 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
    Points : 11 252
    Points
    11 252
    Par défaut
    Bref, on y voit la même chose :
    • Requêtes récursives induites par le parsing hard de la requête, mais sans importance.
    • Un nombre important de lecture physique
    • Un nombre important de lecture en mode consistent
    • Temps d’attente important dans la lecture en mode monobloc des données, très probablement d’un(des) index(es).

    Peut-on avoir aussi le plan d’exécution pour cette requête ?

  19. #39
    Membre expérimenté

    Homme Profil pro
    Inscrit en
    Mars 2010
    Messages
    536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 536
    Points : 1 359
    Points
    1 359
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        4      0.02       0.02          0          0          0           0
     
    Execute      3      0.00       0.00          0          0          0           1
    Fetch        2     41.30     244.17     542230    4183975          0         101
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        9     41.32     244.20     542230    4183975          0         102
     
    Misses IN library cache during parse: 2
     
    Elapsed times include waiting ON following events:
      Event waited ON                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message TO client                       6        0.00          0.00
      SQL*Net message FROM client                     6      119.34        179.59
      db file sequential READ                    542230        0.17        209.16
      SQL*Net more DATA TO client                     5        0.00          0.00
    Lorsqu'il existe une grande différence entre elapsed et cpu (224,20-41,32 = 182,88 secondes) comme c'est le cas ici, cela veut dire que vous avez passé du temps à attendre quelque chose. Ce quelque chose est représenté par db file sequential READ. Cet événement est souvent synonyme d'un accès via index. Ce qui, manifestement, est en contradiction avec le premier vrai plan d’exécution que vous avez présenté pour le id_type_document = 10 où la majeure partie du temps était consommée dans un FULL TABLE SCAN (synonyme de db file scattered READ) de la table document.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
      ------------------------------------------------------------------------------------------------------------------
      | Id  | Operation                         | Name              | Starts | E-Rows | A-Rows |   A-Time   | Buffers | 
      ------------------------------------------------------------------------------------------------------------------
      |* 10 |       TABLE ACCESS FULL           | DOCUMENT          |      1 |   4187K|   4173K|00:00:12.52 |     460K
    Votre requête s'est-elle mise à générer 4.183.975 en utilisant un INDEX sur la table DOCUMENT? ce qui expliquerait peut-être la différence dans le temps de réponse contenue dans la trace(244,20) et celui fournit dans le premier vrai plan d’exécution (12,52 secondes pour le FULL TABLE SCAN et 43 secondes en tout)?

    Dommage que le plan d’exécution n'a pas été inclus dans cette trace.

    Si vous n'êtes pas satisfait par le temps de réponse il faudra faire une optimisation manuelle comme l'a fait Jonathan Lewis dans un contexte qui ressemble un peu au votre mais où pour lui c'était l'opération ORDER BY qui posait le plus problème ce qui n'est pas votre cas ici.

    http://jonathanlewis.wordpress.com/2...l-optimisation

    En rédigeant ces quelques lignes j'ai revu votre requête et il me semble que la jointure externe suivante
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    LEFT OUTER JOIN
                DOCUMENT documentco2_ 
                    ON sousdossie1_.ID_SOUS_DOSSIER=documentco2_.ID_SOUS_DOSSIER
    doit être remplacée par une simple jointure à cause de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    AND documentco2_.ID_TYPE_DOCUMENT='10'
    Bien Respectueusement
    www.hourim.wordpress.com

    "Ce qui se conçoit bien s'énonce clairement"

  20. #40
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2 947
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 2 947
    Points : 5 846
    Points
    5 846
    Par défaut
    Juste pour te donner quelques liens qui peuvent t'intéresser :
    db file sequential read

    Et sur asktom, pour quelques pistes de reflexions :
    Wait event: DB file sequential read

    Mohamed, Il a utilisé la requête de Waldar, il est donc impossible de comparer le tkprof avec les précédents plans.
    jalaval, normalement le tkprof devrait contenir le plan réel dans la section Row Source Operation, sinon regénère un plan pour cette requête, par contre on a l'air loin des 25s dont tu parlais.

Discussions similaires

  1. Temps de reponse sur Select avec Jointure
    Par Guigsounet dans le forum SQL
    Réponses: 15
    Dernier message: 30/07/2010, 11h29
  2. Réponses: 1
    Dernier message: 27/04/2010, 10h07
  3. Requête select avec jointure sur des enregistrements inexitant.
    Par faistoiplaisir dans le forum Langage SQL
    Réponses: 2
    Dernier message: 06/11/2009, 18h36
  4. problème de performance sur requête avec Tsearch2
    Par Morpheas dans le forum PostgreSQL
    Réponses: 0
    Dernier message: 05/02/2008, 13h25
  5. Problème performance SELECT avec jointure
    Par Netgamer dans le forum Requêtes
    Réponses: 7
    Dernier message: 05/08/2005, 11h20

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