[10gR2] Plan d'exécution : Fichier TKPROF

Plan d'exécution : Fichier TKPROF

Bonjour les consultant, je veux avoir votre avis à propos de la trace ci-dessous, que ce que ne marche pas ??
Je crois que l'index TOSTOCK_IDX1 ne sert à rien dans ce cas, n'est ce pas ??

Code:

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
********************************************************************************
 
SELECT       COD_DEPOT,COD_ZONE,COD_RACK,COD_MEUBLE,COD_NIVEAU,ETAT_CMD,
  TYP_EMPLAC,COD_STOCKEUR,COD_ARTICLE,SUM_QTE_PALC,SUM_QTE_COL,SUM_QTE_UVC,
  NUM_LOT,NUM_PAL,DAT_LIMITE,SUM_POIDS_NET,SUM_POIDS_BRUT,COD_STATUT,DOUANE,
  DAT_FIFO,NUM_CMD,OCCUP_LARG,OCCUP_PROF,OCCUP_HAUT,COD_SUPPORT,NUM_LET 
FROM
 SVUE1520 WHERE SVUE1520.SUM_QTE_UVC > 0 and (COD_DEPOT=:1) and (COD_STOCKEUR=
  :2) and (COD_ARTICLE=:3) and (NUM_PAL=:4) order by COD_DEPOT, COD_ZONE, 
  lpad(COD_RACK,3,'0'), COD_MEUBLE, COD_NIVEAU, COD_STOCKEUR, COD_ARTICLE, 
  NUM_PAL, ETAT_CMD desc
 
 
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.03       0.11          9       1238          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.03       0.11          9       1238          0           1
 
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 155  
 
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT ORDER BY (cr=1238 pr=9 pw=0 time=113303 us)
      1   FILTER  (cr=1238 pr=9 pw=0 time=113248 us)
      1    HASH GROUP BY (cr=1238 pr=9 pw=0 time=113235 us)
      1     NESTED LOOPS OUTER (cr=1238 pr=9 pw=0 time=113067 us)
      1      NESTED LOOPS OUTER (cr=1235 pr=9 pw=0 time=113039 us)
      1       NESTED LOOPS  (cr=1232 pr=9 pw=0 time=112997 us)
      1        NESTED LOOPS OUTER (cr=5 pr=0 pw=0 time=90 us)
      1         TABLE ACCESS BY INDEX ROWID TOARTICLE (cr=3 pr=0 pw=0 time=43 us)
      1          INDEX UNIQUE SCAN PK_TOARTICLE (cr=2 pr=0 pw=0 time=27 us)(object id 334046)
      1         TABLE ACCESS BY INDEX ROWID TOFAMILLE (cr=2 pr=0 pw=0 time=33 us)
      1          INDEX UNIQUE SCAN PK_TOFAMILLE (cr=1 pr=0 pw=0 time=9 us)(object id 334124)
      1        TABLE ACCESS BY INDEX ROWID TOSTOCK (cr=1227 pr=9 pw=0 time=112896 us)
   9031         INDEX RANGE SCAN TOSTOCK_IDX1 (cr=42 pr=0 pw=0 time=9186 us)(object id 334260)
      1       TABLE ACCESS BY INDEX ROWID TOCMD_ENT (cr=3 pr=0 pw=0 time=28 us)
      1        INDEX UNIQUE SCAN PK_TOCMD_ENT (cr=2 pr=0 pw=0 time=17 us)(object id 334069)
      0      TABLE ACCESS BY INDEX ROWID TOEMPLAC (cr=3 pr=0 pw=0 time=17 us)
      0       INDEX UNIQUE SCAN PK_TOEMPLAC (cr=3 pr=0 pw=0 time=12 us)(object id 334118)

Etant donné que SVUE1520 est une vue, il faut voir sa définition pour bien analyser le plan.

L'accès via l'index TOSTOCK_IDX1 est désastreux! Ses statistiques sont à jour ?
Après il faut avoir plus d'informations pour aller plus loin.

Bonjour,
Y a-t-il un problème à ce que ça mette 113 millisecondes pour exécuter cette requête ?
Si, l'index TOSTOCK_IDX1 sert à filtrer les 9031 lignes en appliquant le préducat sur ses colonnes. Pour amélorer les perfs, il faut éviter d'aller voir la table TOSTOCK pour les 9030 lignes qu'on ne veut pas. Il faudrait voir le plan d'exécution (autotrace, dbms_xplan, etc) avec les predicats, et rajouter à l'index les colonnes sur lequelles portent les predicats de la ligne 12 du plan d'exécution.
Cordialement,
Franck.