creation d'un index

Version imprimable

Voir 40 message(s) de cette discussion en une page

La suite ....

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
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
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=30314 Card=67321 Byt
          es=13060274)
 
   1    0   NESTED LOOPS (OUTER) (Cost=17 Card=1 Bytes=65)
   2    1     NESTED LOOPS (OUTER) (Cost=10 Card=1 Bytes=39)
   3    2       TABLE ACCESS (BY INDEX ROWID) OF 'F_POLICES' (Cost=3 C
          ard=1 Bytes=13)
 
   4    3         INDEX (UNIQUE SCAN) OF 'PK_POL_IDENT' (UNIQUE) (Cost
          =2 Card=1)
 
   5    2       VIEW (Cost=7 Card=1 Bytes=26)
   6    5         SORT (GROUP BY) (Cost=7 Card=2 Bytes=16)
   7    6           TABLE ACCESS (BY INDEX ROWID) OF 'F_PRIME' (Cost=7
           Card=2 Bytes=16)
 
   8    7             INDEX (RANGE SCAN) OF 'IND_PRM_PTRPOLIDENT' (NON
          -UNIQUE) (Cost=3 Card=6)
 
   9    1     VIEW (Cost=7 Card=1 Bytes=26)
  10    9       SORT (GROUP BY) (Cost=7 Card=2 Bytes=16)
  11   10         TABLE ACCESS (BY INDEX ROWID) OF 'F_PRIME' (Cost=7 C
          ard=2 Bytes=16)
 
  12   11           INDEX (RANGE SCAN) OF 'IND_PRM_PTRPOLIDENT' (NON-U
          NIQUE) (Cost=3 Card=6)
 
  13    0   SORT (UNIQUE) (Cost=29340 Card=67321 Bytes=13060274)
  14   13     FILTER
  15   14       NESTED LOOPS (Cost=28366 Card=67321 Bytes=13060274)
  16   15         HASH JOIN (Cost=28366 Card=67321 Bytes=12790990)
  17   16           TABLE ACCESS (FULL) OF 'T_POL_ETAT' (Cost=7 Card=4
          2 Bytes=1512)
 
  18   16           HASH JOIN (OUTER) (Cost=28356 Card=67331 Bytes=103
          68974)
 
  19   18             HASH JOIN (Cost=19290 Card=47449 Bytes=6595411)
  20   19               NESTED LOOPS (Cost=1815 Card=44864 Bytes=37237
          12)
 
  21   20                 NESTED LOOPS (Cost=2 Card=1 Bytes=31)
  22   21                   TABLE ACCESS (BY INDEX ROWID) OF 'F_PRODUI
          TASS' (Cost=1 Card=1 Bytes=16)
 
  23   22                     INDEX (UNIQUE SCAN) OF 'PK_PAS_IDENT' (U
          NIQUE)
 
  24   21                   TABLE ACCESS (BY INDEX ROWID) OF 'F_BRANCH
          EASS' (Cost=1 Card=1 Bytes=15)
 
  25   24                     INDEX (UNIQUE SCAN) OF 'PK_BAS_IDENT' (U
          NIQUE)
 
  26   20                 INDEX (FAST FULL SCAN) OF 'IDX_DIEGO' (UNIQU
          E) (Cost=1813 Card=44864 Bytes=2332928)
 
  27   19               TABLE ACCESS (BY INDEX ROWID) OF 'F_POLICES' (
          Cost=17142 Card=335952 Bytes=18813312)
 
  28   27                 INDEX (RANGE SCAN) OF 'IND_POL_PTRPASID' (NO
          N-UNIQUE) (Cost=504 Card=6)
 
  29   18             INDEX (FAST FULL SCAN) OF 'IDX_DIEGO2' (UNIQUE)
          (Cost=3761 Card=15773533 Bytes=236602995)
 
  30   15         INDEX (UNIQUE SCAN) OF 'PK_IN_IDENT' (UNIQUE)
  31   14       SORT (AGGREGATE)
  32   31         TABLE ACCESS (BY INDEX ROWID) OF 'F_SIT_OBJET_RISQUE
          ' (Cost=4 Card=1 Bytes=15)
 
  33   32           INDEX (RANGE SCAN) OF 'IND_SOR_PTRPOLID' (NON-UNIQ
          UE) (Cost=3 Card=2)
 
Statistics
----------------------------------------------------------
       3354  recursive calls
          0  db block gets
      59207  consistent gets
      58249  physical reads
          0  redo size
       1652  bytes sent via SQL*Net to client
        677  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
         31  sorts (memory)
          0  sorts (disk)
          3  rows processed

19/08/2009, 11h22
breizh76

Pour les statistiques, on passe ainsi de

281300 consistent gets
280353 physical reads

à:

59207 consistent gets
58249 physical reads

Ce qui est pas mal du tous.... mais cela reste encore tres évelé

d'autant plus qu'ils sont en fast full scan
19/08/2009, 11h41
farenheiit

Qu'as tu changé dans ta requête ?
tu ne veux pas mettre les alias devant les noms de colonnes en jointure ? on ne sait pas quelle table est jointe avec laquelle en lisant la requête

Salut !

Pour optimiser une requête, le mieux, c'est de commencer par la comprendre...

Tu récupères au total 3 lignes sans GROUP BY : combien de lignes sont renvoyées sans le distinct ?

Si c'est sensiblement le même ordre de grandeur sans le distinct, on peut imaginer que tes jointures sont sensées être assez bonnes... et dans ces cas, tu peux imaginer assez facilement la manière dont tu aimerais qu'elle s'exécute.

Le truc qui semble le plus sensible à part ça, c'est :
Code:

1 2 3 4 5 6 7 8 9 AND ( (F_SIT_OBJET_RISQUE.SOR_IDENT = (SELECT MIN (SOR_IDENT) FROM F_SIT_OBJET_RISQUE s2 WHERE s2.SOR_PTRPOLID = POL_IDENT AND s2.SOR_PTRSORSUIVID = 0)) OR (F_SIT_OBJET_RISQUE.SOR_IDENT IS NULL)) AND SOR_PTRPOLID(+) = laPolice.POL_IDENT AND SOR_PTRSORSUIVID(+) = 0
[EDIT]
En fait, comme le dit Farenheit, soit tu préfixes tes colonnes partout dans la requête, soit tu expliques avec des mots quel est le lien entre les différentes tables, et quel résultat tu cherches à atteindre...

[/EDIT]

Enfin, le plan d'exécution est très laid... et donc difficilement exploitable à mon sens. Je suppose que c'est la sortie de l'autotrace qui est mal formatée.
Ressors le avec :
Code:

1 2 3 4 5 6 EXPLAIN PLAN FOR TaRequete / SELECT * FROM TABLE(dbms_xplan.display)
(En ayant les lignes assez larges, pagesize 0 ou je ne sais quoi d'autre pour que le tout soit lisible)

24/08/2009, 11h49
breizh76

Merci beaucoup pour cette réponse. C'est clair que le plan d'execution est du coup beaucoup plus lisible.

Je vais essayer ce que vous me dites et je vous tiens au courant de que cela donne...

Voir 40 message(s) de cette discussion en une page