Problème comportement Oracle

Bonjour,

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

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

Citation:

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.

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

En vous remerciant.
LBO72.

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.

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

Citation:

Envoyé par LBO72

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.

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:

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 :

alors que si je fais :

Code:

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,

Quel est le type de votre champ NU_CONTRAT ?

Le champ est VARCHAR2(15).

Merci.
LBO72.