INDEX pas utilisé avec les <

Version imprimable

Bonjour

J'ai un problème avec la requête suivante

Code:

1
2
3
4
5
6
7
8
9
10
11
12
SELECT
*
FROM
	DWH_SIS_APPLICATION.DWH_MOIS DWH_MOIS
	,SIS_APPLICATION.I_INVESTIGATIONS I_INVESTIGATIONS
	,SIS_APPLICATION.L_LOCALISATIONS L_LOCALISATIONS
	,DWH_SIS_APPLICATION.DWH_RR_DM_MOIS DRDM
WHERE
	I_INVESTIGATIONS.ID_INVESTIGATION = L_LOCALISATIONS.ID_INVESTIGATION
	AND DRDM.DM_MOIS=DWH_MOIS.DM_MOIS
	AND DRDM.D_FIRST_MONTH < I_INVESTIGATIONS.D_END

J'ai un index sur tous les champs utilisés dans la where clause.

DWH_MOIS contient les mois à calculer
DWH_RR_DM_MOIS contient tous les RRRRMM jusque 2023 (indexs sur tous les champs de cette table
Il y a des L_LOCALISATIONS dans I_INVESTIGATIONS

Dans AND DRDM.D_FIRST_MONTH < I_INVESTIGATIONS.D_END, si je me mets un = à la place de <, il utilise tous les indexs parfaitement. Par contre si je mets un <, il utilise pas les index.

Je ne comprend pas pourquoi ! Une idée ?

Merci,

EDIT

AVEC =

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
 
SELECT STATEMENT Optimizer Mode=FIRST_ROWS		11  	 	27  	 	      	             	 
  TABLE ACCESS BY INDEX ROWID	SIS_APPLICATION.L_LOCALISATIONS	1  	39  	2  	 	      	             	 
    NESTED LOOPS		11  	869  	27  	 	      	             	 
      NESTED LOOPS		8  	320  	11  	 	      	             	 
        NESTED LOOPS		1  	27  	2  	 	      	             	 
          INDEX FULL SCAN	DWH_SIS_APPLICATION.DWH_MOIS_PK	24  	120  	1  	 	      	             	 
          TABLE ACCESS BY INDEX ROWID	DWH_SIS_APPLICATION.DWH_RR_DM_MOIS	1  	22  	1  	 	      	             	 
            INDEX UNIQUE SCAN	DWH_SIS_APPLICATION.DWH_RR_MOI_PK	1  	 	0  	 	      	             	 
        TABLE ACCESS BY INDEX ROWID	SIS_APPLICATION.I_INVESTIGATIONS	8  	104  	9  	 	      	             	 
          INDEX RANGE SCAN	SIS_APPLICATION.I_I_INV_D_END	9  	 	1  	 	      	             	 
      INDEX RANGE SCAN	SIS_APPLICATION.LLOC_UK	1  	 	1

AVEC <

Code:

1
2
3
4
5
6
7
8
9
10
11
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
 
SELECT STATEMENT Optimizer Mode=FIRST_ROWS		236 K	 	19  	 	      	             	 
  HASH JOIN		236 K	30 M	19  	 	      	             	 
    TABLE ACCESS FULL	DWH_SIS_APPLICATION.DWH_RR_DM_MOIS	263  	5 K	3  	 	      	             	 
    NESTED LOOPS		209  	11 K	15  	 	      	             	 
      NESTED LOOPS		9  	468  	11  	 	      	             	 
        TABLE ACCESS FULL	SIS_APPLICATION.L_LOCALISATIONS	9  	351  	2  	 	      	             	 
        TABLE ACCESS BY INDEX ROWID	SIS_APPLICATION.I_INVESTIGATIONS	1  	13  	1  	 	      	             	 
          INDEX UNIQUE SCAN	SIS_APPLICATION.IOND_PK	1  	 	0  	 	      	             	 
      INDEX FAST FULL SCAN	DWH_SIS_APPLICATION.DWH_MOIS_PK	23  	115  	0

27/02/2008, 17h50
mnitu
Je dirais plutôt il utilise les indexes parce que les « index full scan » et « index range scan » ne sont pas synonymes de parfaitement.
La réponse standard qui ne fait pas avancer vraiment les choses est « parce que l’optimiseur trouve que c’est mieux de ne pas les utiliser ». Il est moins évident, bien sûr, de dire pour quoi il trouve ça.
- Comment les statistiques sont calculée et sont elles à jour ?
- Quel est le type de données pour DWH_MOIS et DWH_RR_DM_MOIS ?
- Est-ce que les cardinalités affichées (colonne Rows) semble correctes ?
28/02/2008, 09h25
orafrance

Déjà expliquons la raison. Avec égale, Oracle trouve LA ligne qui va faire la jointure et donc passe par le ROWID, l'accès le plus directe. Si tu as un inférieur, alors Oracle va chercher une liste de lignes qui vont permettre de faire la jointure. Si cette liste est grande, les données ramenées dans les tables jointes seront plus nombreuses. Du coup, il peut effectivement être plus intéressant de faire des FTS.

Note qu'un accès par index s'accompagne d'un accès à la table (sauf si l'index contient toutes les colonnes utilisées dans la requête) exemple :

Citation:

TABLE ACCESS BY INDEX ROWID DWH_SIS_APPLICATION.DWH_RR_DM_MOIS 1 22 1
INDEX UNIQUE SCAN DWH_SIS_APPLICATION.DWH_RR_MOI_PK 1 0

L'index permet de retrouver la ligne dans la table et un accès à la table est nécessaire pour récupérer la données. Ainsi, tu comprends bien que si tu ramènes beaucoup de données (il me semble que c'est + de 20% des données de la table par défaut) il vaut mieux faire un FTS plutôt qu'un accès à l'index + un accès à la table... du peut gagner quelques précieux accès disque ;)

Merci pour vos réponses,

Actuellement ce n'est pas la requête utilisée pour la chargement mais j'essaie de trouver mieux. Actuellement ça ressemble à ça.
Code:

1 2 3 4 5 6 7 8 9 10 SELECT * FROM DWH_SIS_APPLICATION.DWH_MOIS DWH_MOIS ,SIS_APPLICATION.I_INVESTIGATIONS I_INVESTIGATIONS ,SIS_APPLICATION.L_LOCALISATIONS L_LOCALISATIONS WHERE I_INVESTIGATIONS.ID_INVESTIGATION = L_LOCALISATIONS.ID_INVESTIGATION AND DWH_MOIS.DM_MOIS <= to_char(nvl(I_INVESTIGATIONS.D_END,sysdate),'RRRRMM')
Pas de table DWH_RR_DM_MOIS.

Nous avons essayé de créer un index sur fonction mais là aussi, ORACLE ne l'utilise pas. Sans doute pour les mêmes raisons que vous m'avez donner.

06/03/2008, 17h12
miloux32

Moi on m'a toujours appris que pour l'index soit utilisé il faut un = sous une forme quelconque . ( =, <=, >= )

enfin ca t'arrange sans doute pas
06/03/2008, 18h02
Yorglaa

tu aurais le plan d'exécution de ta dernière requête ?
ainsi que les volumétries des tables STP...
07/03/2008, 10h11
13thFloor

Un histogramme sur la colonne DWH_MOIS.DM_MOIS peut éventuellement aider
Avec '>', l'optimiseur a des règles de gestion pour la sélectivité estimée des données.
Par exemple, avec une bind variable, il s'attend à rechercher 5% des lignes.
Mais le comportement est-il le même avec '<' ?
Voir note Note:68992.1