Discussion :

[souch]

Bonjour à tous,

je débarque sous Oracle (pas facile ) et tente de passer une appli de firebird ) à Oracle 10g, en commençant mes tests, je fais direct une syncope en voyant le temps requis pour une requête toute bête sur de petites tables ...

J'ai certainement fait une erreur grosse comme un éléphant quelque part, voici donc la structure des mes deux tables, ainsi que la requête incriminée :

Temps d'exécution : entre 0.35s et 0.60s en local sur le serveur via Sql developer.

Table E_Examens (27500 lignes)
PrimaryKey integer (number(*,0) sur E_EXAMENS.IDEXAMEN
index integer (number(*,0) sur E_EXAMENS.IDPATIENT
index Asc timestamp(0) sur E_EXAMENS.DateExamen
ForeignKey (Cascade) sur p_patients.idpatient

Table P_Patients (20000 lignes)
PrimaryKey integer (number(*,0) sur P_PATIENTS.IDPATIENT
index varchar2(32 char) sur P_PATIENTS.Nom

Requête :

Code :

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

1
2
3
4
SELECT p.Nom, e.DATEEXAMEN
FROM E_EXAMENS e
INNER JOIN P_PATIENTS p on p.idpatient = e.idpatient
ORDER By e.DateExamen Asc

Plan :

Code :

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

1
2
3
4
5
6
"Optimizer"	"Cost"	"Cardinality"	"Bytes"	"Partition Start"	"Partition Stop"	"Partition Id"	"ACCESS PREDICATES"	"FILTER PREDICATES"
"SELECT STATEMENT"	"ALL_ROWS"	"1123"	"26471"	"2673571"	""	""	""	""	""
"SORT(ORDER BY)"	""	"1123"	"26471"	"2673571"	""	""	""	""	""
"HASH JOIN"	""	"507"	"26471"	"2673571"	""	""	""	""P"."IDPATIENT"="E"."IDPATIENT""	""
"TABLE ACCESS(FULL) MEDIREPORT.E_EXAMENS"	""	"249"	"26470"	"582340"	""	""	""	""	""
"TABLE ACCESS(FULL) MEDIREPORT.P_PATIENTS"	""	"97"	"22341"	"1764939"	""	""	""	""	""

Pourquoi le plan ne tient t'il point compte de mes index ?

Merci bcp à tout ceux qui prendront le temps de se poser la question

Souch

[orafrance]

tout simplement parce que tu sélectionnes toutes les lignes des 2 tables

Si tu rajoutes une jointure qui limite le résultat, tu devrais utiliser un index

[souch]

Salut OraFrance,

Merci pour ta réponse, en effet ca aide de limiter le nombre de retour, cependant mes requettes gardaient des plans foireux (tout en natural, pas ou peut d'index utilisés).
Je viens de trouver la solution :
passer le optimizer_mode en mode 'RULE' (http://www.adp-gmbh.ch/ora/tuning/optimizer.html), je n'ai pas encore assez potassé pour piger pourquoi ca marche mieux avec, mais le résultat est équivoque : toutes mes requetes sont a présent faites en passant exclusivement par les indexs

[orafrance]

si c'est le cas ça veut dire que tes stats ne sont pas à jour. Le mode RULE est à éviter SURTOUT en 10g

[souch]

ha ? Pourtant c'est diablement efficace ^^
Question bête, comment mettre à jours mes stats ?
cette méthode est elle la bonne ?

Code :

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

analyze table <table name> compute statistics;

Edit : après avoir passé le compute statistics sur toute mes tables et être repassé en mode 'ALL_ROWS', mes plans sont toujours faux (quasiment tout en access full), si je repasse en CHOOSE ou RULE, c'est impec...

[orafrance]

un beau plan d'exécution n'est pas forcément synonyme de performance. RULE est obsoléte. Quelle tête elle a ta requête maintenant ? Combien de lignes tu récupères ?

et ANALYZE aussi est obsoléte, tu dois utiliser DBMS_STATS.