[9i][Optimisation] Optimiser une requete

Version imprimable

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

> Aline, je suis pas d'accord sur les dates : Si les paramètres sont de 01/01 au 31/12 tu balayes toute la table.
>Nuke_y :
1 / Est ce que Colis.debut_date toujours <= Colis.fin_date ?
2/ Tu n'as pas la PK de colis dans Evenements (Identifiant1+identifiant2 + Discriminant) ?
Ca voudrait dire que tu as 2 colis avec le même identifiant (1+2) et les évènements que tu récupères sont les évènements des 2 colis ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SELECT DISTINCT 
      Colis.Identifiant1, Colis.Identifiant2,  Colis.Identifiant3, 
      Colis.Identifiant4,  Colis.Identifiant5, 
      Evenements.Identifiant6, signification.Valeur1 
FROM 
    COLIS, 
    EVENEMENTS, 
    SIGNIFICATION 
WHERE 
   	Colis.Identifiant1      	IN (130, 290) 
AND Colis.Identifiant4      	IS NULL 
AND Colis.Identifiant5      	IS NULL 
AND Colis.debut_date       		> :0 
AND Colis.fin_date          	< :1 
AND Colis.annulée          		= 0 
AND Colis.livrée          		= 'EC' 
AND Evenements.Identifiant1 	= Colis.Identifiant1
AND Evenements.Identifiant2 	= Colis.Identifiant2
-- AND Evenements.Discriminant = Colis.Dicriminant ??
AND Evenements.action_date    	BETWEEN :0 AND :1 
AND signification.Identifiant1 	= Evenements.Identifiant1
AND signification.Identifiant6 	= Evenements.Identifiant6
AND signification.Identifiant7 	= 'C'

23/02/2006, 11h15
nuke_y

Aline> non pas de Fk entre Grosse_Table et Enorme_Table.

McM> 1) Oui, par contre on couvre des périodes entre debut et livraison qui peuvent couvrir 1 ou 2 mois, pas 1 année
2) Je sais, mais le taux d'erreur est faible. Disons que ce n'est PAS une base transactionnelle mais de reporting. Le but c'est de sortir un taux en % à 1 chiffre après la virgule sur plusieurs millions de colis alors si on a 10 colis par mois qui récupèrent les événements des autres...
23/02/2006, 11h28
McM

Elle est bizarre ta base :lol:

Des PK qui ne sont pas uniques
Des tables Filles qui ne récupèrent pas toute la PK de la table Mère
:roll:
En cours Oracle DBA-Tuning, on apprend que l'opti se passe tout d'abord par lors de la phase de Modélisation.
23/02/2006, 11h31
nuke_y

Quelle modélisation ?

Attends pour savoir à quoi correspondent certains champs on est obligé d'aller voir l'Univers Business Objects qui est greffé dessus :?

Moi je serais pour qu'on corrige un peu tout ça mais alors il faudrait 2 mois à 3 DBA pour en sortir quelquechose de correct...

Salut à tous...
Nuke, est-ce tu peux me confirmer que cette requête fonctionne convenablement (requête originale SANS Minuscule_Table)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Select Distinct
        Grosse_Table.Identifiant1
        , Grosse_Table.Identifiant2
        , Grosse_Table.Identifiant3
        , Grosse_Table.Identifiant4
        , Grosse_Table.Identifiant5
        , Enorme_Table.Identifiant6
From
        Grosse_Table
        , Enorme_Table
Where           Grosse_Table.Identifiant1 = Enorme_Table.Identifiant1
        AND     Grosse_Table.Identifiant2 = Enorme_Table.Identifiant2
        AND     Grosse_Table.Identifiant1 IN (130, 290)
        AND     Grosse_Table.debut_date >= :0
        AND     Grosse_Table.debut_date <= :1
        AND     Grosse_Table.fin_date >= :0
        AND     Grosse_Table.fin_date <= :1
        AND     Enorme_Table.action_date >= :0
        AND     Enorme_Table.action_date <= :1
        AND     Grosse_Table.annulée = 0
        AND     Grosse_Table.livrée = 'EC'
        AND     Grosse_Table.Identifiant5 IS NULL
        AND     Grosse_Table.Identifiant4 IS NULL

si oui, as-tu essayé de factoriser cette première requête pour ensuite prendre les infos de Minuscule_Table que sur le RESULTAT :

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
With
    FIRSTSTEP as (
                Select Distinct
                        Grosse_Table.Identifiant1 
                        , Grosse_Table.Identifiant2 
                        , Grosse_Table.Identifiant3 
                        , Grosse_Table.Identifiant4 
                        , Grosse_Table.Identifiant5 
                        , Enorme_Table.Identifiant6
                From
                        Grosse_Table
                        , Enorme_Table
                Where           Grosse_Table.Identifiant1 = Enorme_Table.Identifiant1 
                        AND     Grosse_Table.Identifiant2 = Enorme_Table.Identifiant2
                        AND     Grosse_Table.Identifiant1 IN (130, 290) 
                        AND     Grosse_Table.debut_date >= :0 
                        AND     Grosse_Table.debut_date <= :1 
                        AND     Grosse_Table.fin_date >= :0 
                        AND     Grosse_Table.fin_date <= :1 
                        AND     Enorme_Table.action_date >= :0 
                        AND     Enorme_Table.action_date <= :1 
                        AND     Grosse_Table.annulée = 0 
                        AND     Grosse_Table.livrée = 'EC' 
                        AND     Grosse_Table.Identifiant5 IS NULL 
                        AND     Grosse_Table.Identifiant4 IS NULL 
                 )
SELECT 
        FIRSTSTEP.Identifiant1 
        , FIRSTSTEP.Identifiant2 
        , FIRSTSTEP.Identifiant3 
        , FIRSTSTEP.Identifiant4 
        , FIRSTSTEP.Identifiant5 
        , FIRSTSTEP.Identifiant6 
        , Minuscule_Table.Valeur1 
FROM 
        FIRSTSTEP
        , Minuscule_Table  
WHERE 
                FIRSTSTEP.Identifiant1 = Minuscule_Table.Identifiant1 
        AND     FIRSTSTEP.Identifiant6 = Minuscule_Table.Identifiant6 
        AND     Minuscule_Table.Identifiant7 = 'C'

dis-moi ce que ça donne...

EDIT :
je suis d'accord avec McM pour dire qu'un between serait assez indiqué pour les dates...

Citation:

Envoyé par Yorglaa

je suis d'accord avec McM pour dire qu'un between serait assez indiqué pour les dates...

En fait non puisque debut_date <= fin_date et s'il n'y a pas d'index sur une des dates, je pense que dans ce cas, le between x 2 n'est pas la meilleure solution. Je préfère la 3ème.
Code:

1 2 3 4 AND Grosse_Table.debut_date >= :0 AND Grosse_Table.debut_date <= :1 AND Grosse_Table.fin_date >= :0 AND Grosse_Table.fin_date <= :1
Code:

1 2 AND Grosse_Table.debut_date BETWEEN :0 AND :1 AND Grosse_Table.fin_date BETWEEN :0 AND :1
Code:

1 2 AND Grosse_Table.debut_date >= :0 AND Grosse_Table.fin_date <= :1

23/02/2006, 14h36
Jaouad

Juste une petite question :

Comment peut on commencer a optimiser sans avoir la cardinalité , le cout (bien qu'il soit facultatif ) et le nombre de linges ramenés. la valeur de bytes ,
Mais également le nombre de lecture , E/S , volume de tri , le volume de REDO et les évènements d'attente

Ce qui va pouvoir vous donner des renseignements précis sur les latc, locks , précision et pertinence des jointures , index , E/S

cela ne remet pas en cause les bonnes volontés et l'expérience de chacun ...
23/02/2006, 15h20
McM

Citation:

Envoyé par Jaouad

Juste une petite question :

Comment peut on commencer a optimiser sans avoir la cardinalité , le cout (bien qu'il soit facultatif ) et le nombre de linges ramenés. la valeur de bytes ,

cela ne remet pas en cause les bonnes volontés et l'expérience de chacun ...

Les cardinalités, les nb de lignes, Nuke_y les a données, non ?
23/02/2006, 15h20
nuke_y

Yorglaa > j'avais déjà testé en enlevant Minuscule_Table et ça tourne en 2mn. J'avais donc essayé une requête en 2 temps mais pas en utilisant le WITH mais en faisant un SELECT ... FROM (SELECT ... FROM Grosse_Table, Enorme_Table), Minuscule_Table et c'est reparti pour des délais énormes (et en plus je ne peux pas trop passer par un système comme ça).

Jaouad > J'ai ENFIN pu répliqué mes données, je vais utiliser ta commande et vous donner une compilation de mes tests et de mes résultats.

En tous cas merci à tous.
23/02/2006, 15h22
Jaouad

Citation:

Envoyé par McM

Citation:

Envoyé par Jaouad

Juste une petite question :

Comment peut on commencer a optimiser sans avoir la cardinalité , le cout (bien qu'il soit facultatif ) et le nombre de linges ramenés. la valeur de bytes ,

cela ne remet pas en cause les bonnes volontés et l'expérience de chacun ...

Les cardinalités, les nb de lignes, Nuke_y les a données, non ?

Mais cela ne suffit pas
23/02/2006, 15h32
Yorglaa

Citation:

Envoyé par nuke_y

Yorglaa > j'avais déjà testé en enlevant Minuscule_Table et ça tourne en 2mn. J'avais donc essayé une requête en 2 temps mais pas en utilisant le WITH mais en faisant un SELECT ... FROM (SELECT ... FROM Grosse_Table, Enorme_Table), Minuscule_Table et c'est reparti pour des délais énormes (et en plus je ne peux pas trop passer par un système comme ça).

Attention !
Utiliser WITH ou Select from (Select ...) ce n'est pas du tout la même chose ! => essaye quand même le WITH...

et pourquoi tu ne pourrait pas utiliser un système comme ça ?

si ton chef ne veux que des syntaxes qu'il comprend, faut peut-être pas qu'en plus il veuille des performances... :wink: non je déconne...
23/02/2006, 15h58
nuke_y

Malheureusement non, ce n'est même pas un problème de politique. Les requêtes sont réalisées sous GENIO qui ne possède pas toutes les nuances du SQL...

je vais essayer ta solution, dès que j'ai déplanté tous mes serveurs :?
23/02/2006, 16h13
McM

Citation:

Envoyé par Jaouad

Citation:

Envoyé par McM

Citation:

Envoyé par Jaouad

Juste une petite question :

Comment peut on commencer a optimiser sans avoir la cardinalité , le cout (bien qu'il soit facultatif ) et le nombre de linges ramenés. la valeur de bytes ,

cela ne remet pas en cause les bonnes volontés et l'expérience de chacun ...

Les cardinalités, les nb de lignes, Nuke_y les a données, non ?

Mais cela ne suffit pas

Je suis pas convaincu : Sortir l'artillerie lourde pour optimiser une requete alors que la base est bancale... Je préfère stabiliser la base, voir ce que redonne la requete et optimiser ensuite.
23/02/2006, 16h28
Jaouad

Mcm :fleche: enfin ce n'est pas l'artillerie lourde de faire un autotrace avec explain et statistique

tu ne peux pas dire ça , c'est pas comme si j'avais demandé un audit complet de la base 8O ...

Voila les premiers résultats pour la requête de départ, sur une période courte (pour pas trop se saturer) :

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
SQL> set timing on
SQL> set autot trace exp stat
SQL>
SQL> SELECT COUNT(1) FROM
  2  (
  3  SELECT DISTINCT G_T1.PARTNER_ID ,
  4  G_T1.TRANSPORT_NO ,
  5  G_T1.SHIPMENT_NO ,
  6  G_T1.CD_EVENT_DELAY ,
  7  G_T1.CD_FAULT_DELAY ,
  8  G_T0.CD_EVENT ,
  9  G_T2.T_CLOCK_STOPPER
 10  FROM DWH."TRACK_EVENT" G_T0,
 11  DWH."SHIPMENT" G_T1,
 12  DWH."TRACK_EVENT_TYPE" G_T2
 13  WHERE
 14  ( G_T1.PARTNER_ID = G_T0.PARTNER_ID AND G_T1.TRANSPORT_NO = G_T0.TRANSPORT_NO  )
 15  AND ( G_T0.CD_EVENT = G_T2.CD_TE_DHL AND G_T0.PARTNER_ID = G_T2.PARTNER_ID  )
 16  AND G_T1.PARTNER_ID IN (130, 290)
 17  AND G_T1.INBOUND_REF_DATE >= '15/02/2006'
 18  AND G_T1.INBOUND_REF_DATE <= '23/02/2006'
 19  AND G_T1.OUTBOUND_REF_DATE >= '15/02/2006'
 20  AND G_T1.OUTBOUND_REF_DATE <= '23/02/2006'
 21  AND G_T0.DT_MVT >= '15/02/2006'
 22  AND G_T0.DT_MVT <= '23/02/2006'
 23  AND G_T1.CANCELED = 0
 24  AND G_T1.DELIVERED = 'EC'
 25  AND G_T1.CD_FAULT_DELAY IS NULL
 26  AND G_T1.CD_EVENT_DELAY IS NULL
 27  AND G_T2.RESPONSABILITE = 'C'
 28  );
 
EcoulÚ : 00 :10 :36.02
 
Plan d'exÚcution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1 Bytes=14)
   1    0   SORT (AGGREGATE)
   2    1     VIEW (Cost=11 Card=1 Bytes=14)
   3    2       SORT (UNIQUE) (Cost=11 Card=1 Bytes=122)
   4    3         TABLE ACCESS (BY INDEX ROWID) OF 'TRACK_EVENT' (Cost
          =2 Card=1 Bytes=27)
 
   5    4           NESTED LOOPS (Cost=4 Card=1 Bytes=122)
   6    5             MERGE JOIN (CARTESIAN) (Cost=3 Card=1 Bytes=95)
   7    6               TABLE ACCESS (BY INDEX ROWID) OF 'SHIPMENT' (C
          ost=2 Card=1 Bytes=62)
 
   8    7                 INDEX (RANGE SCAN) OF 'I_SHIPMENT_DELIVERED_
          OUTBOUND' (NON-UNIQUE) (Cost=4 Card=4)
 
   9    6               BUFFER (SORT) (Cost=1 Card=1 Bytes=33)
  10    9                 INLIST ITERATOR
  11   10                   TABLE ACCESS (BY INDEX ROWID) OF 'TRACK_EV
          ENT_TYPE' (Cost=2 Card=1 Bytes=33)
 
  12   11                     INDEX (RANGE SCAN) OF 'I_TRACK_EVENT_TYP
          E_CD_TE' (UNIQUE) (Cost=1 Card=2)
 
  13    5             INLIST ITERATOR
  14   13               INDEX (RANGE SCAN) OF 'I_TRACK_EVENT_EVENTS' (
          NON-UNIQUE) (Cost=1 Card=1)
 
 
Statistiques
----------------------------------------------------------
          0  recursive calls
          0  db block gets
  125070034  consistent gets
      17851  physical reads
     130344  redo size
        197  bytes sent via SQL*Net to client
        275  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
          1  rows processed

Voila les résultats sans la Minuscule Table :

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
SQL> set timing on
SQL> set autot trace exp stat
SQL>
SQL> SELECT COUNT(1) FROM
  2  (
  3  SELECT DISTINCT G_T1.PARTNER_ID ,
  4  G_T1.TRANSPORT_NO ,
  5  G_T1.SHIPMENT_NO ,
  6  G_T1.CD_EVENT_DELAY ,
  7  G_T1.CD_FAULT_DELAY ,
  8  G_T0.CD_EVENT
  9  FROM DWH."TRACK_EVENT" G_T0,
 10  DWH."SHIPMENT" G_T1
 11  WHERE
 12  ( G_T1.PARTNER_ID = G_T0.PARTNER_ID AND G_T1.TRANSPORT_NO = G_T0.TRANSPORT_NO  )
 13  AND G_T1.PARTNER_ID IN (130, 290)
 14  AND G_T1.INBOUND_REF_DATE >= '15/02/2006'
 15  AND G_T1.INBOUND_REF_DATE <= '23/02/2006'
 16  AND G_T1.OUTBOUND_REF_DATE >= '15/02/2006'
 17  AND G_T1.OUTBOUND_REF_DATE <= '23/02/2006'
 18  AND G_T0.DT_MVT >= '15/02/2006'
 19  AND G_T0.DT_MVT <= '23/02/2006'
 20  AND G_T1.CANCELED = 0
 21  AND G_T1.DELIVERED = 'EC'
 22  AND G_T1.CD_FAULT_DELAY IS NULL
 23  AND G_T1.CD_EVENT_DELAY IS NULL
 24  );
 
EcoulÚ : 00 :00 :20.09
 
Plan d'exÚcution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=10 Card=1 Bytes=12)
   1    0   SORT (AGGREGATE)
   2    1     VIEW (Cost=10 Card=1 Bytes=12)
   3    2       SORT (UNIQUE) (Cost=10 Card=1 Bytes=89)
   4    3         TABLE ACCESS (BY INDEX ROWID) OF 'TRACK_EVENT' (Cost
          =2 Card=1 Bytes=27)
 
   5    4           NESTED LOOPS (Cost=3 Card=1 Bytes=89)
   6    5             TABLE ACCESS (BY INDEX ROWID) OF 'SHIPMENT' (Cos
          t=2 Card=1 Bytes=62)
 
   7    6               INDEX (RANGE SCAN) OF 'I_SHIPMENT_DELIVERED_OU
          TBOUND' (NON-UNIQUE) (Cost=4 Card=4)
 
   8    5             INLIST ITERATOR
   9    8               INDEX (RANGE SCAN) OF 'I_TRACK_EVENT_EVENTS' (
          NON-UNIQUE) (Cost=1 Card=3)
 
 
 
 
 
Statistiques
----------------------------------------------------------
          0  recursive calls
          5  db block gets
    1160389  consistent gets
       3407  physical reads
          0  redo size
        198  bytes sent via SQL*Net to client
        275  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          1  sorts (disk)
          1  rows processed

Alors Yorglaa, avec le WITH on arrive à faire la requête et on gagne en temps :

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
91
SQL> set timing on
SQL> set autot trace exp stat
SQL>
SQL> SELECT COUNT(1) FROM
  2  (
  3  With
  4      FIRSTSTEP as (
  5  SELECT DISTINCT G_T1.PARTNER_ID ,
  6  G_T1.TRANSPORT_NO ,
  7  G_T1.SHIPMENT_NO ,
  8  G_T1.CD_EVENT_DELAY ,
  9  G_T1.CD_FAULT_DELAY ,
 10  G_T0.CD_EVENT
 11  FROM DWH."TRACK_EVENT" G_T0,
 12  DWH."SHIPMENT" G_T1
 13  WHERE
 14  ( G_T1.PARTNER_ID = G_T0.PARTNER_ID AND G_T1.TRANSPORT_NO = G_T0.TRANSPORT_NO  )
 15  AND G_T1.PARTNER_ID IN (130, 290)
 16  AND G_T1.INBOUND_REF_DATE >= '15/02/2006'
 17  AND G_T1.INBOUND_REF_DATE <= '23/02/2006'
 18  AND G_T1.OUTBOUND_REF_DATE >= '15/02/2006'
 19  AND G_T1.OUTBOUND_REF_DATE <= '23/02/2006'
 20  AND G_T0.DT_MVT >= '15/02/2006'
 21  AND G_T0.DT_MVT <= '23/02/2006'
 22  AND G_T1.CANCELED = 0
 23  AND G_T1.DELIVERED = 'EC'
 24  AND G_T1.CD_FAULT_DELAY IS NULL
 25  AND G_T1.CD_EVENT_DELAY IS NULL
 26  )
 27  SELECT
 28          FIRSTSTEP.PARTNER_ID
 29          , FIRSTSTEP.TRANSPORT_NO
 30          , FIRSTSTEP.SHIPMENT_NO
 31          , FIRSTSTEP.CD_EVENT_DELAY
 32          , FIRSTSTEP.CD_FAULT_DELAY
 33          , FIRSTSTEP.CD_EVENT
 34          , TRACK_EVENT_TYPE.T_CLOCK_STOPPER
 35  FROM
 36          FIRSTSTEP
 37          , DWH.TRACK_EVENT_TYPE
 38  WHERE
 39                  FIRSTSTEP.PARTNER_ID = DWH.TRACK_EVENT_TYPE.PARTNER_ID
 40          AND     FIRSTSTEP.CD_EVENT = DWH.TRACK_EVENT_TYPE.CD_TE
 41          AND     DWH.TRACK_EVENT_TYPE.RESPONSABILITE = 'C'
 42  );
 
EcoulÚ : 00 :05 :46.01
 
Plan d'exÚcution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1 Bytes=14)
   1    0   SORT (AGGREGATE)
   2    1     VIEW (Cost=11 Card=1 Bytes=14)
   3    2       VIEW (Cost=11 Card=1 Bytes=103)
   4    3         SORT (UNIQUE) (Cost=11 Card=1 Bytes=129)
   5    4           TABLE ACCESS (BY INDEX ROWID) OF 'TRACK_EVENT' (Co
          st=2 Card=1 Bytes=27)
 
   6    5             NESTED LOOPS (Cost=4 Card=1 Bytes=129)
   7    6               NESTED LOOPS (Cost=3 Card=1 Bytes=102)
   8    7                 TABLE ACCESS (BY INDEX ROWID) OF 'SHIPMENT'
          (Cost=2 Card=1 Bytes=62)
 
   9    8                   INDEX (RANGE SCAN) OF 'I_SHIPMENT_DELIVERE
          D_OUTBOUND' (NON-UNIQUE) (Cost=4 Card=4)
 
  10    7                 INLIST ITERATOR
  11   10                   TABLE ACCESS (BY INDEX ROWID) OF 'TRACK_EV
          ENT_TYPE' (Cost=2 Card=1 Bytes=40)
 
  12   11                     INDEX (RANGE SCAN) OF 'I_TRACK_EVENT_TYP
          E_CD_TE' (UNIQUE) (Cost=1 Card=2)
 
  13    6               INLIST ITERATOR
  14   13                 INDEX (RANGE SCAN) OF 'I_TRACK_EVENT_EVENTS'
           (NON-UNIQUE) (Cost=1 Card=1)
 
 
Statistiques
----------------------------------------------------------
         22  recursive calls
          0  db block gets
   57894112  consistent gets
          2  physical reads
          0  redo size
        198  bytes sent via SQL*Net to client
        275  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed

23/02/2006, 17h36
aline

Je me trompe peux-être, mais il semble que tes stats ne soient pas à jour.

Quand on voit la différence de cout de ton explain plan et le nombre de consistent gets que tu fais....

ce qui est rassurant, c'est qu'il parait trop élevé et que soit àprès le recalcul des stats, soit avec un hint, on doit pouvoir optimiser.

De manière intuitive, j'ai quand même l'impression depuis le début qu'il y a un nested loop qui devrait être remplacé par un hash_join.
Ce n'est peut-être pas très scientifique, mais que donne ta requete avec ce hint?
/*+use_hash(G_T0)*/
23/02/2006, 17h44
nuke_y

Je te confirme que
1) les stats ne sont pas à jour
2) je me dis depuis 2 jours qu'il faut que je vous le dise et j'ai oublié, donc je suis impardonnable.

Sinon euh ton hint je l'utilise comment ?

EDIT :
Les stats datent de 10 jours, sachant que le volume augmenté mais proportionnellement sur les 2 tables, c'est grave ?
23/02/2006, 19h35
nuke_y

Bon alors le hint il provoque un MERGE JOIN CARTESIAN...

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