Optimisation requête

Version imprimable

Bonjour,

J'ai une requête un peu longue. voici une trace tkprof :

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
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.04       0.06          0          0          0           0
Execute      2      0.02       0.02          0          0          0           0
Fetch       20      2.46      48.09       6354      17626        174         187
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       24      2.52      48.17       6354      17626        174         187
 
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 41  (ETUD)
 
Rows     Row Source Operation
-------  ---------------------------------------------------
     94  SORT UNIQUE 
     97   HASH JOIN 
    343    INDEX FAST FULL SCAN (object id 79939)
     97    HASH JOIN 
     97     FILTER 
     98      HASH JOIN OUTER 
     95       TABLE ACCESS FULL IM_INTASAI 
 151595       INDEX FAST FULL SCAN (object id 42234)
  30296     TABLE ACCESS FULL ARTDGENE 
 
 
Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   GOAL: CHOOSE
     94   SORT (UNIQUE)
     97    HASH JOIN
    343     INDEX   GOAL: ANALYZED (FAST FULL SCAN) OF 'PARSOCPV_2' 
                (NON-UNIQUE)
     97     HASH JOIN
     97      FILTER
     98       HASH JOIN (OUTER)
     95        TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'IM_INTASAI'
 151595        INDEX   GOAL: ANALYZED (FAST FULL SCAN) OF 
                   'IM_INTCLIV_2' (NON-UNIQUE)
  30296      TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'ARTDGENE'

La phase fetch me semble trop longue. Pourquoi cela prend autant de temps ? Temps réseau ?

11/01/2006, 13h54
sboffin

La ou il y a des (full) c'est pcq tu fais un full table scan pour chercher tes donnees. Il y a un (full) pcq ton select n'utilise probablement pas un indexe de la table.

Regarde les indexes sur la table et utilise les. Cela devrait reduire le temps d'execution.
11/01/2006, 14h11
Débéa

ok pour les full.

Mais si tu regardes le temps d'execution n'est pas enorme. C'est le temps fetch qui pose problème. C'est donc l'extraction des 187 lignes qui prend du temps. (a noter qu'il n'y a pas d'order by dans le select)

Etes-vous d'accord avec mon analyse ?
11/01/2006, 14h31
lalystar

Les phases de préparations d'un select ne coutent quasi rien (parse...). Tout le calcul est fait au niveau de chaque fetch.

Etant donné que dans ton plan, ca se termine par un tri, je pense que c'est le premier fetch qui est couteux, il faut calculer tout le resultset, le trier pour renvoyer la première ligne, ensuite les autres fetch doivent être bcp plus rapide.

Laly.
11/01/2006, 14h50
Débéa

je pensais que dans la fase EXECUTE, Oracle identifie les lignes concernées. Dans la fase FETCH il ne reste plus qu'a ramener les 187 lignes.

Me confirmes-tu que cela n'est pas le cas ?
11/01/2006, 15h39
plaineR

Jaouad explique chaque étape dans son tuto : :wink:
http://oracle.developpez.com/guide/tuning/tkprof/#LV