[8i] optimisation de requete

Bonjour,

Je rencontre un problème avec l'utilisation d'un progiciel qui génère des requêtes de ce type

Code:

---

1 2 3 4 5 6 7 8

select mesures0_.MESURE_CODE as MESURE_C1_, mesures0_.MESURE_LIBELLE as MESURE_L2_, mesures0_.MESURE_ACTIVE as MESURE_A5_, mesures0_.ICOMMENT as ICOMMENT, mesures0_.MESURE_TYPE as MESURE_T4_, mesures0_.NATURE_RISQUE as NATURE_R6_, mesures0_.RISQUE_CODE as RISQUE_C7_ from MESURES mesures0_ where (NATURE_RISQUE IS NOT NULL)AND(MESURE_LIBELLE LIKE 'Obligation d''un triangl%')AND(RISQUE_CODE='A')

---

Lorsque je fais un explain plan je constate un FTS sur la table MESURES (330.000 enregistrements) ce qui n'est pas énorme.

Je pense que le problème vient de la clause LIKE mais je ne sais pas trop comment faire ..

Merci pour votre aide ;)

Bonne fin de journée,
Alain

Combien de lignes doit retourner la requête ?

Essayez de rajouter un index sur (RISQUE_CODE, MESURE_LIBELLE).

Que est-ce que vous avez comme index sur la table en question ?

Ceci est aussi possible:
Pb de perf sur des grands champs avec l'opérateur like.
http://www.dba-oracle.com/oracle_tip..._sql_index.htm

Voir l'article de Laurent Schneider.
http://laurentschneider.com/wordpres...me-likebc.html

Bonjour,

Merci pour vos réponse, j'ai déjà un index sur la colonne RISQUE_CODE et je pense que la réponse réside dans l'article pointé par boutade80 :

http://www.dba-oracle.com/oracle_tip..._sql_index.htm

Je n'ai jamais utilisé ce type d'index, je vais creuser un peu le sujet afin de savoir s'il n'y a pas d'effet de bord.

Savoir par exemple si les requêtes doivent être réécrites car j'ai cru comprendre que l'utilisation de ce type d'index nécessitait l'utilisation du mot clef 'CONTAINS' à la place du mot clef 'LIKE'.

Merci bien,
Alain

Like '%ABC%' n'est pas la même chose que like 'ABC%'.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

SQL> set autotrace traceonly explain SQL> select * from emp where ename like 'ABC%';   Plan d'exÚcution ---------------------------------------------------------- Plan hash value: 2765129497   --------------------------------------------------------------------------------------   | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |   --------------------------------------------------------------------------------------   | 0 | SELECT STATEMENT | | 1 | 37 | 2 (0)| 00:00:01 |   | 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 37 | 2 (0)| 00:00:01 |   |* 2 | INDEX RANGE SCAN | IX_EMP | 1 | | 1 (0)| 00:00:01 |   --------------------------------------------------------------------------------------     Predicate Information (identified by operation id): ---------------------------------------------------   2 - access("ENAME" LIKE 'ABC%') filter("ENAME" LIKE 'ABC%')   SQL> select * from emp where ename like '%ABC%';   Plan d'exÚcution ---------------------------------------------------------- Plan hash value: 3956160932   -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 37 | 3 (0)| 00:00:01 | |* 1 | TABLE ACCESS FULL| EMP | 1 | 37 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------   Predicate Information (identified by operation id): ---------------------------------------------------   1 - filter("ENAME" LIKE '%ABC%')   SQL>

---

Le test de la non nullité dans la clause where empêche toute utilisation d'un index, d'ou le FTS.

Citation:

---

Envoyé par SheikYerbouti

Le test de la non nullité dans la clause where empêche toute utilisation d'un index, d'ou le FTS.

---

Salut @ SheikYerbouti
Déjà, je ne vois pas dans ce cas comment ta remarque s’applique; à priori la colonne testée avec NOT NULL n’est pas indexée.

Le test de non nullité empêchera certainement d'utiliser des indexes référençant la colonne "NATURE_RISQUE", mais je ne vois pas pourquoi la requête n'utilisera pas des indexes sur les autres colonnes.
Sinon,
Je crois que l'index sur la colonne "RISQUE_CODE" n'est pas assez sélectif.
Ta colonne "MESURE_LIBELLE" est indexée?

Merci de poster le résultat de cette requête :

Code:

---

SELECT index_name, column_name, column_position FROM user_ind_columns WHERE table_name = 'MESURES' ORDER BY 1,3

---

Rachid A.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

SQL> set autotrace traceonly explain stat SQL> SQL> select * from muse where muse_date is not null and id = 11942;   Elapsed: 00:00:00.01   Execution Plan ---------------------------------------------------------- Plan hash value: 3518730075   -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 18 | 4 (0)| 00:00:01 | |* 1 | TABLE ACCESS BY INDEX ROWID| MUSE | 1 | 18 | 4 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | ID_IDX | 1 | | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------------

---

Rachid A.

Désolé, le message auquel j'ai répondu a disparu entre-temps ;)

Rachid A.

Je viens de créer un index sur la colonne MESURE_LIBELLE type btree mais je ne vois pas vraiment de différence en terme de temps de réponse entre le FTS et le passage par l'index.

Il faut que je puisse tester au travers du progiciel.

J'indiquerai le résultat des tests la semaine prochaine.

Merci pour vos réponses

Bon week à tous,
Alain