Discussion :

[LBO72]

Bonjour,

Je suis en Oracle 10GR2 et j'ai un souci que je vous expose ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
prod)>select * from CONTRAT partition (m200901) where NU_CONTRAT = '102795462';

Execution Plan
----------------------------------------------------------
          0
SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1 Bytes=308)
          1                  0
  PARTITION RANGE (SINGLE) (Cost=11 Card=1 Bytes=308)
          2                  1
    TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'CONTRAT' (TABLE) (Cost=11 Card=1 Bytes=308)
          3                  2
      INDEX (SKIP SCAN) OF 'PK_CONTRAT' (INDEX (UNIQUE)) (Cost=10 Card=1)

La réponse en quasi-instannée

prod)>select * from CONTRAT partition (m200901) where nu_affa in ('112946548','102795462');

Execution Plan
----------------------------------------------------------
0
SELECT STATEMENT Optimizer=CHOOSE (Cost=44037 Card=2 Bytes=616)

1 0
PARTITION RANGE (SINGLE) (Cost=44037 Card=2 Bytes=616)

2 1
TABLE ACCESS (FULL) OF 'CONTRAT' (TABLE) (Cost=44037 Card=2 Bytes=616)

Ma table CONTRAT est partitionnée, les stats sur la partition sont bonnes.
Pourquoi dans un cas, l'optimiseur Oracle utilise l'index et pas dans l'autre.
Merci de vos réponses.
LBO72.

[LBO72]

Petit complément :
Dans le second cas, j'ai ma réponse au bout de 40s !!!!!

En vous remerciant.
LBO72.

[13thFloor]

Je pense à un "problème" de sélectivité du CBO.
En effet, il n'y a pas plus sélectif qu'une égalité : 1/nb de valeurs distinctes
Le IN est moins sélectif (je ne connais la formule).
Un hint index_ss devrait te donner le même plan que celui de ta 1ère requête.

[LBO72]

Merci bien 13thFloor,

Je testerai le index_ss hint et te tiens au courant. Sinon, par hasard, connais-tu un bon livre en français qui traite ce genre de problématique de performance ?

En te remerciant.
LBO72

[Waldar]

Pourquoi dans un cas, l'optimiseur Oracle utilise l'index et pas dans l'autre.

Parce que dans un cas vous filtrez sur une colonne indexée (qui se trouve être la clef primaire) et pas dans l'autre.

Créez un index local sur le champ NU_AFFA.

[LBO72]

Merci Waldar pour votre réponse,

Dans le deuxieme cas, je me suis planté de requête. Au fait elle est identique à la première sauf qu'elle utilise un IN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
prod)>select * from CONTRAT partition (m200901) where NU_CONTRAT in ('112946548','102795462');

Execution Plan
----------------------------------------------------------
0
SELECT STATEMENT Optimizer=CHOOSE (Cost=44037 Card=2 Bytes=616)

1 0
PARTITION RANGE (SINGLE) (Cost=44037 Card=2 Bytes=616)

2 1
TABLE ACCESS (FULL) OF 'CONTRAT' (TABLE) (Cost=44037 Card=2 Bytes=616)

alors que si je fais :

[LBO72]

alors que si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
prod)>  SELECT * FROM CONTRAT PARTITION(m200901) 
         WHERE NU_CONTRAT IN('102795462')

Execution Plan
----------------------------------------------------------
          0
SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1 Bytes=308)
          1                  0
  PARTITION RANGE (SINGLE) (Cost=11 Card=1 Bytes=308)
          2                  1
    TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'CONTRAT' (TABLE) (Cost=11 Card=1 Bytes=308)
          3                  2
      INDEX (SKIP SCAN) OF 'PK_CONTRAT' (INDEX (UNIQUE)) (Cost=10 Card=1)

La réponse est instantanée.

Cdlt,

[Waldar]

Quel est le type de votre champ NU_CONTRAT ?

[LBO72]

Le champ est VARCHAR2(15).

Merci.
LBO72.