Est-il possible d'utiliser un index précis dans une requète sql en 10g?

Oracle Database 10g Enterprise Edition Release 10.2.0.2.0

Bonjour,

J'ai une table d'affectation possédant une date de début.
j'ai creé un index 'TEST' sur cette date.(Un index avec la fonction TRUNC(start_date))

Lorsque j'effectue la requète suivante, voici le résultat de l'explain plan:

Code:

---

1 2 3 4 5 6 7 8

select a.* from P_ASSIGNMENTS a where TRUNC(start_date) = TRUNC(TO_DATE('18/09/1997','DD/MM/YYYY'))   Operation Object Name Rows Bytes Cost SELECT STATEMENT Optimizer Mode=ALL_ROWS 127 38 TABLE ACCESS BY INDEX ROWID P_ASSIGNMENTS 127 10 K 38 INDEX RANGE SCAN TEST 51

---

On utilise bien l'index.
J'aurais bien aimé savoir si avec la requète suivante, il est possible de faire référence à cet index.

Code:

---

1 2 3 4 5 6 7

select a.* from P_ASSIGNMENTS a where TRUNC(start_date) = (select max(a1.start_date) from p_assignments a1 where a1.person_id = a.person_id and a1.sequence = a.sequence and a1.end_date is null)

---

Car pour le moment, il construit la "vue temporaire" et fait un table acces full sur P_ASSIGNMENT a.

Merci d'avance.

0. La 2nde requête est-elle lente ? Si elle ne rame pas, on ne tune pas.
1. Quel est le plan d'exécution de la 2nde requête ?
2. Les stats sont-elles à jours ? Sont-elles calculées avec des histogrammes ?
3. Pourquoi ne pas utiliser HAVING ?

Non , pour le moment elle ne rame pas de trop, mais il n'y a que 12680 tuples dans cette table et elle est destinée à en recevoir bcps plus à l'avenir.

Donc je me demandais comment améliorer les perf.

Voici le plan de la seconde requète:

Code:

---

1 2 3 4 5 6 7 8

Operation Object Name Rows Bytes Cost   SELECT STATEMENT Optimizer Mode=ALL_ROWS 22 60 HASH JOIN 22 2 K 60 VIEW SYS.VW_SQ_1 2 K 73 K 17 HASH GROUP BY 2 K 65 K 17 INDEX FAST FULL SCAN P_ASSIGN_PE_IDX 2 K 65 K 16 TABLE ACCESS FULL P_ASSIGNMENTS 12 K 1 M 42

---

Pour ce qui est des stats j'ai executé une commande de dbms_stat pour mettre a jour toutes les stats du shemas ,pour la manière de les calculer, je ne sais vraiment pas comment elles le sont.

Et pour la Clause Having, je ne vois pas comment l'utiliser à part dans un group by.

C'est surtout le nombre de blocs qui intéresse l'optimiseur, pas le nb de lignes.
L'optimiseur a jugé plus performant de faire un fts plutôt que de lire blocs d'index+blocs de tables.
Si tu veux réellement utiliser, place un hint dans la requête:

Code:

---

1 2	SELECT /*+ index(a,test) */ a.*

---

Si tu veux vérifier que ta requête utiliseras ton index quand il y aura davantage de volume, positionnes les stats à des valeurs importantes (en blocs notamment).

Attention :

TRUNC(start_date) :arrow: fonction sur la colonne :arrow: l'index sur start_date ne peut pas être utilisé. Il faut un index de fonction ;)

Edit : oublie ce que je dis, j'avais pas bien lu :oops:

Par contre, je t'invite à utiliser une fonction analytique qui t'évitera d'utiliser 2 fois la table :)

pas de problèmes de perf => pas de hint ! :roll:

+1 12000 lignes, donc le FULL est probablement plus performant.

C'est tout l'intérêt des stats, le CBO sait s'adapter en fonction de la volumétrie :)

Ok merci beaucoup.