Discussion :

[squallJ]

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 :

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

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 :

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

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.

[LeoAnderson]

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 ?

[squallJ]

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 :

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

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.

[13thFloor]

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 :

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

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).

[orafrance]

Attention :

TRUNC(start_date) fonction sur la colonne 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

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

[LeoAnderson]

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

[orafrance]

+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

[squallJ]

Ok merci beaucoup.