Discussion :

[kervoaz]

Bonjour,

je vous présente les données de ma question:
une table toute bête avec par exemple 2 colonnes: col1 et col2
la table comporte x rows et pour 1% des lignes col1 = Y
et 99% des lignes col1 = N
on met un index classique, donc dans notre cas de mauvaise sélectivité, sur col1.
Et on requête avec une clause where sur col1 avec une variable liée(col1=:var)
Vous m'arrêtez si je dis des bêtises mais dans ces conditions l'optimizer va sûrement préférer un full plutôt que prendre l'index (pour :var =Y ou N). Donc lorsque :var=Y on peut difficilement avoir un plan plus merdique.

Maintenant On rajoute un histogramme sur col1, tout à fait indiqué dans mon cas.
En admettant que la requete soit en memoire et que son plan actuel soit un full scan, si je fais ma query col1=:var avec :var=Y
QUE VA T'IL SE PASSER?
Le sql va t'il etre reparsé? le plan va t'il changé? si le sql n'est jamais dechargé de la memoire, le plan du full sera toujours choisit?

Merci pour votre aide

[orafrance]

oui, ça va changer parce que les stats sont recalculées

[kervoaz]

Bonjour,

ok donc maintenant je suis avec un plan d'exécution avec un index.
Si rien ne change par ailleurs(requête toujours en shared pool, pas de recalcul de stat,..),
Est ce que je peux me retrouver avec un full scan suivant la valeur de la bind variable?

Merci

[orafrance]

oui puisque tu as calculer les histogrammes. Si tu as un index déséquilibré il n'est pas impossible de faire un FULL SCAN. Mais attention, un FTS n'est pas forcément mauvais. Si une valeur retourne 90% (chiffre pris arbitrairement ) des données de la table, l'accés par index pourra être plus couteux.

[DAB.cz]

J'ai testé ça (10.1.0.4):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
create table tb (col1 number, col2 char (1));
 
delete from tb;
insert into tb (col1, col2)
  select level, decode (mod (level, 100), 1, 'Y', 'N')
    from dual
    connect by level <= 5000000;
commit;
 
create index tbii on tb (col2);
 
exec dbms_stats.gather_table_stats ('TEST', 'TB')
 
variable c char (1)
exec :c := 'N'
select count (1) c
  from tb where col2 = :c;
 
variable c char (1)
exec :c := 'Y'
select count (1) c
  from tb where col2 = :c;

Oracle choisit bon chemin (FTS ou index) d'après le premier ordre, mais ne la change pour une autre valeur.

DAB

[kervoaz]

Merci dab.cz,

c'est un peu là où je voulais en arriver.
A part de réécrire le sql sans bind variable, y a un gros problème.

De plus je n'ai rien trouvé pour forcer une requête à être reparsée ou déchargée de la mémoire.

Vous faites comment vous?

Merci