Plan d'exécution pas logique

Bonjour,

j'ai une sous-requête de la forme suivante :

Code:

---

1 2 3 4 5 6 7 8

select ... from T1 where T1.C1 = constante and T1.C2 = constante and T1.C3 = constante and T1.C4 = constante and T1.C5 = constante and ...

---

La table T1 commporte 16194 lignes et les index suivants (tous valides) pour les colonnes utilisées :
IDX2 (non unique) sur T1(C1,C2) - 48 clés distinctes
IDX4 (non unique) sur T1(C1,C2,C3,C4,C5,...) - 16194 clés distinctes
IDX6 (non unique) sur T1(C3) - 2084 clés distinctes
IDX7 (non unique) sur T1(C4) - 107 clés distinctes

Logiquement, et c'est limpide, l'optimiseur devrait utiliser lindex IDX4, et bien non ...

Plan en 8i (MODE=RULE) :

Code:

---

1 2 3

SELECT STATEMENT Optimizer Mode=RULE TABLE ACCESS BY INDEX ROWID T1 INDEX RANGE SCAN IDX2

---

Plan en 9i (MODE=CHOOSE) : c'est pire au point de vue performances (les stats ont été calculées pour index et tables)

Code:

---

1 2 3 4 5 6 7 8 9 10

Operation Object Name Rows Bytes Cost   SELECT STATEMENT Optimizer Mode=CHOOSE 1 3 TABLE ACCESS BY INDEX ROWID T1 1 292 3 BITMAP CONVERSION TO ROWIDS BITMAP AND BITMAP CONVERSION FROM ROWIDS INDEX RANGE SCAN IDX6 1 BITMAP CONVERSION FROM ROWIDS INDEX RANGE SCAN IDX7 1

---

Je ne vois pas de justification à ce plan...

IDX4 contient combien de colonnes ? Ca donne quoi coté perf si tu forces l'index par un hint ?

IDX4 possède 10 colonnes...
Si je force cet index par un hint, en 9i ça ne change rien, et en 8i il fait comme en 9i, en utilisant IDX6 et IDX7 ...

8O c'est énorme 10 colonnes pour un index... t'as des requêtes qui utilisent ces 10 colonnes pour faire des jointures ?

je n'en sais rien, je ne connais pas l'appli, mais cette on m'a remonté cette requête qui est beaucoup plus longue après migration vers 9.
Mais je n'arrive pas à voir pourquoi il veut à tout prix éviter cet index...

parce qu'il est trop gros et donc probablement pas intéressant au regard des stats :?

Citation:

---

Envoyé par pat29

IDX4 possède 10 colonnes...
Si je force cet index par un hint, en 9i ça ne change rien, et en 8i il fait comme en 9i, en utilisant IDX6 et IDX7 ...

---

Le plan d'exec devrait changer. Vérifies la syntaxe de ton hint : /*+ index(alias_de_table IDX4) */
Espace après le '+', espace entre l'alias de la table et l'index

Code:

---

1 2 3

select /*+ (t idx4) */ FROM T1 t WHERE ...

---

C'est vrai que 10 colonnes dans un index, ça na va pas inciter l'optimiseur à l'utiliser. Ce n'est pas aussi logique et limpide. Il y a un coût à calculer (ou estimer). Si l'optim n'utilise pas IDX4 c'est qu'il a trouvé un chemin d'accès moins couteux. Met les stats à jour sur la table et tous ses index et relance sans hint d'index : même résultat ? Quel est le résultat en mode rule ?