Explication sur un plan d'exécution

Bonjour.

je suis 10g sous 2k3 Server.
J'ai une requête dont je ne parviens à m'expliquer le plan d'exécution.

Voici le plan d'exécution étant entendu que
- la table P a un inex sur A
- la table CIZ a un index sur A et un index sur B
- j'ai exécuté les commandes suivantes

Code:

---

1 2 3 4 5

alter table CIZ move; alter index CIZ.IndexSurA rebuild; alter index CIZ.IndexSurB rebuild; execute dbms_stat.gather_table_stats ('CIZ');

---

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

>explain plan for select * from p inner join ciz on (ciz.a = p.a and ciz.b = 113);   ExplicitÚ.   >select plan_table_output from table(dbms_xplan.display());   PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 362659792   -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 256K| 36M| | 8703 (2)| 00:01:45 | |* 1 | HASH JOIN | | 256K| 36M| 11M| 8703 (2)| 00:01:45 | | 2 | TABLE ACCESS FULL| P | 90526 | 10M| | 322 (2)| 00:00:04 | |* 3 | TABLE ACCESS FULL| CIZ | 1771K| 55M| | 4030 (3)| 00:00:49 | --------------------------------------------------------------------------------------------   Predicate Information (identified by operation id): ---------------------------------------------------   1 - access("CIZ"."a"="P"."a") 3 - filter("CIZ"."b"=113)   16 ligne(s) sÚlectionnÚe(s).

---

Malgré tout, j'ai un FULL ACCESS TABLE sur CIZ.

Ce que je ne comprends pas, c'est, d'une part, pourquoi oracle n'utilise pas l'index CIZ.IndexSurB.
D'autre part, le full access est-il vraiment sur la table ou bien sur le résultat de la jointure.

Merci de vos lumières.

Olivier

Quelle est la sélectivité du filtre sur b ?
Si ça garde une grosse partie des lignes, alors il est plus rapide d'accéder à la table plutôt que d'accéder à l'index, puis pour chaque ligne indiquée par l'index aller chercher la ligne dans la table.


EDIT: s'il y a peu de colonnes réellement utiles dans la requête, il est possible de les inclure dans l'index (qui sera alors couvrant), pour ne pas avoir à faire l'aller-retour entre la table et l'index. Mais bien sûr, cela a un coût : à la fois en place et en temps de mise à jour de l'index.

Hello,
Idem Rei Ichido.
Combien de lignes pour le critère b=113 ?

Code:

---

1 2	select count(*) from ciz where b=113; select count(*) from ciz;

---

Si beaucoup de lignes le full est justifié.
Si non, il manque peut être un histogramme sur la colonne b.

Effectivement, je n'y avais pas fait attention, mais ce filtre ramène 46% des 4 millions de lignes de la table.
En regardant le chiffre plan, je crois que du coup, ça répond aussi à ma deuxième question.

Quant à modifier l'index, je ne peux pas le faire

Merci beaucoup à tous les deux.