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

Administration Oracle Discussion :

Interprétation résultat tkprof


Sujet :

Administration Oracle

  1. #1
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut Interprétation résultat tkprof
    Bonjour,

    J'observe des ralentissements sur une de mes BDD oracle.

    J'ai lancé les traces et une analyse tkprof mais j'ai besoin d'aide pour interpréter les résultats s'il vous plait ?

    Ci-dessous l'analyse TKPROF :

    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
    SELECT count(*)
    FROM
     TB_COMMANDES A0 WHERE A0.DATECOMMANDE >= :1
     
     
    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      5.75      71.09      81044      92524          0           1
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        3      5.75      71.09      81044      92524          0           1
     
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 60  (ACHATS)
    Si quelqu'un peut m'aider à comprendre ce tableau, ce serait parfait.

    Merci d'avance.

  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
    Votre requête prend 71s à s'exécuter : 5s de temps processeur (colonne CPU) et probablement le reste lié aux entrées sorties (colonne disk). Il faut tracer avec les waits events pour avoir plus de détail (DBMS_MONITOR.SESSION_TRACE_ENABLE(waits=> true) à partir de la 10g).

    Voir http://oracle.developpez.com/guide/tuning/tkprof/

    et http://download.oracle.com/docs/cd/B...race.htm#i4642

  3. #3
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    comme le précise pifor, c'est les wait events qui diront ce qu'il s'est passé pendant 71.09 -5.75=65.35 secondes
    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  4. #4
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    Merci pour vos réponses. Je regarde les wait.

  5. #5
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    La table v$session_event donne les résultats suivants :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    SID	EVENT	TOTAL_WAITS	TOTAL_TIMEOUTS	TIME_WAITED	AVERAGE_WAIT	MAX_WAIT	TIME_WAITED_MICRO
    10	latch free	4	0	0	0	0	74
    10	buffer busy waits	28*595	0	4*003	0	16	40*031*801
    10	db file sequential read	14*285	0	2*687	0	19	26*868*332
    10	db file scattered read	119*648	0	29*284	0	29	292*839*606
    10	direct path read	17	0	0	0	0	79
    10	direct path write	8	0	0	0	0	15
    10	direct path read (lob) 	18	0	0	0	0	53
    10	SQL*Net message to client	3*392	0	0	0	0	1*733
    10	SQL*Net more data to client	2*538	0	5	0	0	52*703
    10	SQL*Net message from client	3*391	0	116*430	34	98*772	1*164*301*787
    Les attentes les plus importantes sont donc ici :
    - db file scattered read
    - SQL*Net message from client

    Il semble que le premier cas est lié aux I/O pour les FULL ACCESS (ce qui correspond à ma trace : beaucoup de FULL ACCESS)
    Par contre, je ne sais pas à quoi correspond le second cas.

  6. #6
    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
    La table v$session_event vous donne des statistiques cumulatives pour la session. Le fichier trace vous donnes les détails d’un traitement. Vous ne pouvez pas tires des conclusions concernant le détail à partir de l'agrégation.

    Pifor vous propose de faire une trace sql étendue pour avoir dans le fichier de trace les événements de type WAIT pour chaque requête.

  7. #7
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    OK.

    Mais pour le moment, je ne dispose pas du package "DBMS_MONITOR" alors que je suis bien sur une 10g. Je vais regarder comment installer le package et vous tiens au courant.

  8. #8
    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
    Pour activer/désactiver la trace SQL étendue
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    alter session set events '10046 trace name context forever, level 12'
    ...
    alter session set events '10046 trace name context off'

  9. #9
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    Merci pour votre aide et désolé pour le temps de réponse....

    J'ai donc ajouté les waits :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    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        0.01          0.01
      db file sequential read                        29        0.01          0.08
      db file scattered read                      27943        0.31         85.52
    Avez-vous une idée ?

    Merci d'avance.

  10. #10
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    db file scattered read
    C'est un full table scan.
    27943 I/O en 85.52 c'est plutôt pas mal (3ms par i/o)

    Soit tu trouve un moyen d'éviter un full table scan, en partitionant par exemple, ou si tu sait que A0.DATECOMMANDE >= :1 est un prédicat très sélectif et qu'un index est intéressant.

    Soit tu essaie d'accélérer les i/o:
    - en moyenne tu lis 81044/27943=3 blocs par i/o tu peux esperer plus (voir db_file_multiblock_read_count et voir la taille des extents)
    - en strippant le filesystem sur plusieurs disques
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  11. #11
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    Merci.

    Le problème est que j'ai déjà un index. Mais j'ai l'impression qu'il ne sert pas :


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          1  SORT AGGREGATE (cr=92524 r=81044 w=0 time=71091850 us)
      11867   TABLE ACCESS FULL COMMANDE (cr=92524 r=81044 w=0 time=71087640 us)
     
     
    Rows     Execution Plan
    -------  ---------------------------------------------------
          0  SELECT STATEMENT   GOAL: CHOOSE
          1   SORT (AGGREGATE)
      11867    INDEX   GOAL: ANALYZED (RANGE SCAN) OF
                   'COMMANDE_DATECOMMANDE' (NON-UNIQUE)

  12. #12
    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
    Il sera bien que vous fournissez un peu plus d’informations si vous voulez avancer, pour exemple le plan d’exécution existant dans le fichier de trace ainsi que le tableau que vous avez fourni la première fois pour voir quelle sont les valeurs actuelles, etc.

  13. #13
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Effectivement,

    L'explain plan montre un accès par index, mais le vrai plan d'exécution fait un full table scan.
    Cela vient du fait que 'A0.DATECOMMANDE >= :1' utilise une bind variable. sans connaitre la valeur qui va être passée, impossible de savoir si l'index est intéressant ou pas. donc ce que fait Oracle (du moins depuis 9i) c'est qu'il fait son plan d'exécution en fonction de la 1ère exécution.

    Peut-être que tu as intérêt à ne pas utiliser une variable ici. Ça dépends du contexte.

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  14. #14
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    La dernière version :

    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
     
    TKPROF: Release 9.2.0.4.0 - Production on Me Sep 22 15:18:32 2010
     
    Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
     
    Trace file: commande_ora_10682.trc
    Sort options: default
     
    ********************************************************************************
    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 count(*)
    FROM
     COMMANDE A0 WHERE A0.DATEDEBUT >= :1
     
     
    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      6.59      87.74      83810      92524          0           1
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        3      6.59      87.74      83810      92524          0           1
     
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 60  (COMMANDE)
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          1  SORT AGGREGATE (cr=92524 r=83810 w=0 time=87748018 us)
      11818   TABLE ACCESS FULL COMMANDE (cr=92524 r=83810 w=0 time=87743828 us)
     
     
    Rows     Execution Plan
    -------  ---------------------------------------------------
          0  SELECT STATEMENT   GOAL: CHOOSE
          1   SORT (AGGREGATE)
      11818    INDEX   GOAL: ANALYZED (RANGE SCAN) OF
                   'COMMANDE_DATEDEBUT' (NON-UNIQUE)
     
     
    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        0.01          0.01
      db file sequential read                        29        0.01          0.08
      db file scattered read                      27943        0.31         85.52
    ********************************************************************************
     
    SELECT A0.c1,A0.C2,A0.C3,A0.C4
    FROM
     COMMANDE A0 WHERE A0.DATEDEBUTRL >= :1 ORDER BY 22 DESC,3
     
     
    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     1182      7.17     101.79      84499      92524          3       11818
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total     1184      7.17     101.79      84499      92524          3       11818
     
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 60  (COMMANDE)
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
      11818  SORT ORDER BY (cr=92524 r=84499 w=690 time=101623039 us)
      11818   TABLE ACCESS FULL COMMANDE (cr=92524 r=83809 w=0 time=101087480 us)
     
     
    Rows     Execution Plan
    -------  ---------------------------------------------------
          0  SELECT STATEMENT   GOAL: CHOOSE
      11818   SORT (ORDER BY)
      11818    TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF
                   'COMMANDE'
          0     INDEX   GOAL: ANALYZED (RANGE SCAN) OF
                    'COMMANDE_DATEDEBUT' (NON-UNIQUE)
     
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                    1183        0.00          0.00
      SQL*Net message from client                  1183        0.06          2.48
      db file scattered read                      27940        0.31         98.69
      db file sequential read                        36        0.01          0.10
      direct path write                               4        0.00          0.00
      direct path read                               10        0.00          0.00
      SQL*Net more data to client                  1176        0.00          0.02
    ********************************************************************************
     
    SELECT c1,C2
    FROM
     COMMERCIAL WHERE ID = :1
     
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse       50      0.00       0.00          0          0          0           0
    Execute     50      0.00       0.00          0          0          0           0
    Fetch       50      0.00       0.00          0        100          0          50
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total      150      0.00       0.00          0        100          0          50
     
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 60  (COMMANDE)
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          1  TABLE ACCESS BY INDEX ROWID COMMERCIAL (cr=2 r=0 w=0 time=26 us)
          1   INDEX UNIQUE SCAN PK_COMMERCIAL (cr=1 r=0 w=0 time=13 us)(object id 27217)
     
     
    Rows     Execution Plan
    -------  ---------------------------------------------------
          0  SELECT STATEMENT   GOAL: CHOOSE
          1   TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF
                  'COMMERCIAL'
          1    INDEX   GOAL: ANALYZED (UNIQUE SCAN) OF 'PK_COMMERCIAL'
                   (UNIQUE)
     
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                     100        0.00          0.00
      SQL*Net message from client                   100        0.02          0.19
    ********************************************************************************
     
    SELECT NOM,ID
    FROM
     CATEGORIE WHERE ID = :1
     
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse       50      0.00       0.00          0          0          0           0
    Execute     50      0.02       0.00          0          0          0           0
    Fetch       50      0.00       0.00          0        100          0          50
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total      150      0.02       0.00          0        100          0          50
     
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 60  (COMMANDE)
     
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          1  TABLE ACCESS BY INDEX ROWID CATEGORIE (cr=2 r=0 w=0 time=17 us)
          1   INDEX UNIQUE SCAN PK_CATEGORIE (cr=1 r=0 w=0 time=8 us)(object id 27199)
     
     
    Rows     Execution Plan
    -------  ---------------------------------------------------
          0  SELECT STATEMENT   GOAL: CHOOSE
          1   TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF 'CATEGORIE'
          1    INDEX   GOAL: ANALYZED (UNIQUE SCAN) OF 'PK_CATEGORIE' (UNIQUE)
     
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                     100        0.00          0.00
      SQL*Net message from client                    99        0.02          0.25
     
     
     
    ********************************************************************************
     
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
     
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse      102      0.00       0.00          0          0          0           0
    Execute    102      0.02       0.00          0          0          0           0
    Fetch     1283     13.76     189.54     168309     185248          3       11919
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total     1487     13.78     189.55     168309     185248          3       11919
     
    Misses in library cache during parse: 0
     
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                    1689        0.00          0.00
      SQL*Net message from client                  1688        0.09          3.49
      db file sequential read                        65        0.01          0.18
      db file scattered read                      55883        0.31        184.21
      direct path write                               4        0.00          0.00
      direct path read                               10        0.00          0.00
      SQL*Net more data to client                  1264        0.00          0.02
      direct path read (lob)                          9        0.00          0.00
     
     
    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
     
      102  user  SQL statements in session.
        0  internal SQL statements in session.
      102  SQL statements in session.
        4  statements EXPLAINed in this session.
    ********************************************************************************
    Trace file: commande_ora_10682.trc
    Trace file compatibility: 9.00.01
    Sort options: default
     
           1  session in tracefile.
         102  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
         102  SQL statements in trace file.
           4  unique SQL statements in trace file.
           4  SQL statements EXPLAINed using schema:
               SYSTEM.prof$plan_table
                 Default table was used.
                 Table was created.
                 Table was dropped.
       63138  lines in trace file.

  15. #15
    Membre averti
    Inscrit en
    Novembre 2002
    Messages
    549
    Détails du profil
    Informations forums :
    Inscription : Novembre 2002
    Messages : 549
    Points : 436
    Points
    436
    Par défaut
    comment calcules tu les statistiques sur la table et les index associés ?

    je désactiverai bien le calcul d'histogrammes pour ma part.
    PpPool

  16. #16
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    Merci.

    Ci-dessous mon script pour la mise à jour des stats :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    EXECUTE DBMS_STATS.DELETE_SCHEMA_STATS(ownname=>'&2');
    EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(ownname=>'&2',estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,method_opt=>'FOR ALL COLUMNS SIZE 1',degree=>2,cascade=>TRUE)
    Et les paramètres de ma BDD :

    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
     
    NAME	VALUE
     
    _trace_files_public	TRUE
    processes	500
    timed_statistics	TRUE
    shared_pool_size	134217728
    shared_pool_reserved_size	10485760
    large_pool_size	16777216
    java_pool_size	16777216
    nls_language	FRENCH
    nls_territory	FRANCE
    control_files	/database/COMMMANDE/control/control_01.ctl, /database/COMMANDE/control/control_02.ctl, /database/COMMANDE/control/control_03.ctl
    db_block_size	8192
    db_cache_size	117440512
    compatible	9.2.0.0.0
    log_buffer	262144
    log_checkpoint_interval	0
    log_checkpoint_timeout	1800
    db_file_multiblock_read_count	16
    fast_start_mttr_target	300
    log_checkpoints_to_alert	FALSE
    undo_management	AUTO
    undo_tablespace	UNDO_001_COMMANDE
    undo_retention	300
    db_domain	
    global_names	FALSE
    instance_name	COMMANDE
    dispatchers	(PROTOCOL=TCP)
    cursor_space_for_time	FALSE
    session_cached_cursors	64
    hash_join_enabled	TRUE
    hash_area_size	10485760
    background_dump_dest	/oracle/admin/COMMANDE/bdump
    user_dump_dest	/oracle/admin/COMMANDE/udump
    core_dump_dest	/oracle/admin/COMMANDE/cdump
    sort_area_size	1048576
    sort_area_retained_size	1048576
    db_name	COMMANDE
    open_cursors	500
    optimizer_mode	CHOOSE
    partition_view_enabled	TRUE
    star_transformation_enabled	FALSE
    optimizer_max_permutations	79000
    optimizer_index_cost_adj	1
    optimizer_index_caching	99
    query_rewrite_enabled	FALSE
    pga_aggregate_target	104857600

  17. #17
    Futur Membre du Club
    Inscrit en
    Novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 22
    Points : 7
    Points
    7
    Par défaut
    J'avance petit à petit sur le sujet.

    Je pense que le problème provient de l'utilisation de bind variables associé à un index sur des dates.

    Pour information, je suis sur une 9i. Je n'ai malheureusement pas la valeur des variables bind. Je ne connais pas non plus le typage de mes variables bind.

    Je pense que le problème vient de là : mais j'ai du mal à identifer une solution ou le problème de manière plus précise.

    Avez-vous des idées sur le sujet ?

  18. #18
    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
    Ça peut tout à fait être une cause du problème, si votre colonne DATEDEBUT est au format DATE et qu'on lui envoie une chaîne de caractères, il va y avoir conversion implicite et donc perte de l'index.

    Il me semble qu'il y a une option pour voir les valeurs des binds variables dans la trace, mais là je laisse mnitu / pachot répondre

  19. #19
    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
    Je ne pense pas du tout que vous avez un problème de variable de liaison (bind variable).
    Mais, bon si vous voulez tester:
    A partir de sqlplus exécutez après avoir activée la trace SQL deux requêtes : une avec une variable de binding et une autre en mettant une date en littéral. Prenez- soin d’utiliser la même valeur pour la date bien sûr. Regardez ensuite le plan d’exécution etc.
    La table commande contient combien des enregistrements. Y a-t-il un index sur la colonne DATECOMMANDE ? Est-ce que la zone peut contenir la valeur nulle ? Avez-vous une date bidon dans la table de type 31/12/2100 qui représente une date à préciser ?

  20. #20
    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
    Citation Envoyé par Waldar Voir le message
    ...
    Il me semble qu'il y a une option pour voir les valeurs des binds variables dans la trace, mais là je laisse mnitu / pachot répondre
    La trace étendue montre les valeurs des variables de binding si l'option a été activée.

Discussions similaires

  1. Aide interprétation résultat
    Par stb007 dans le forum Administration
    Réponses: 0
    Dernier message: 06/11/2013, 16h07
  2. [8] Interprétation résultat tkprof
    Par couse1 dans le forum Administration
    Réponses: 1
    Dernier message: 20/02/2013, 15h39
  3. [10.2.0.1 sur W2K3] interprétation rapport TKPROF
    Par fred_04510 dans le forum Administration
    Réponses: 2
    Dernier message: 08/12/2010, 13h05
  4. Oracle9i interprétation de tkprof
    Par groy1 dans le forum Oracle
    Réponses: 3
    Dernier message: 19/04/2008, 01h18
  5. Interprétation résultats StatsPack
    Par mnitu dans le forum SQL
    Réponses: 2
    Dernier message: 13/11/2007, 18h18

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