Discussion :

[vivabarça]

Bonjour a tous ,

ma question est simple : je fais un simple select sur une vue oracle :

Code :

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

select * from ma_vue where id in (la liste de mes ids);

sachant que ma liste d'ids contient 100 valeurs. le probleme que je rencontre seulement depuis aujourd'hui c'est un temps de traitement dépassant 4 minutes pour ce select !!
sachant que je suis sur base oracle et que j'utilise un client oracle ainsi que OCI pour l'execution de mes requetes.
j'aimerais savoir pourquoi l'utilisation de l'operateur IN rend le traitement lent ?
j'ai rencontré le meme probleme sur une requete similaire : ou j'ai remplacé le IN par un NOT IN (car pour le coup c'etait possible), puis ma requete marche bien.
pour ce deuxième cas je ne peux pas inverser car le nombre d'ids dans la base dépasse le million.

Merci d'avance

[fsmrel]

j'aimerais savoir pourquoi l'utilisation de l'operateur IN rend le traitement lent ?

Soumettez votre requête à un EXPLAIN PLAN et regardez comment sont utilisés les index.

[vivabarça]

Soumettez votre requête à un EXPLAIN PLAN et regardez comment sont utilisés les index.

Bonsoir,

d'abord merci pour votre réponse.
ne connaissant pas EXPLAIN PLAN je voudrais savoir juste comment et pourquoi l'utiliser dans mon cas ? (surtout pourquoi).
sachant que quand j'execute la requete sous sqldeveloper : le temps de réponse est inferieur a 2 secondes, quel est le probleme qui peut etre a l'origine de cette lenteur inexpliquée quand ma requete est envoyé via un script php au serveur ?

Merci

[A.Herobic]

Bonjour,

pour utiliser un explain plan, la démarche est explique ici. La doc oracle, pour plus d'explication est ici.

Un explain plan permet de savoir comment Oracle va exécuter votre requête par une estimation des coûts.

Dans votre cas, il n'est pas normal qu'une requête vous prenne 2 seconde sur un outil et beaucoup plus longtemps sur un autre. La première question que je me poserais, c'est combien de lignes sont renvoyé par la requête (si c'est 10 millions, votre requête est bonne, c'est certainement votre réseau qui trinque)

[fsmrel]

Pour compléter au plan général quant au rôle d'EXPLAIN :

Quand vous codez une instruction SELECT, vous êtes au stade du QUOI, vous ne dites pas COMMENT les tables seront accédées. C’est l’optimiseur du SGBD qui s’en chargera, en fonction notamment de la volumétrie des tables et des turbos (les index) branchés sur ces tables. Quand une requête se traîne, c’est bien souvent parce qu’un index qui va bien est absent. Pour en avoir le cœur net, vous demandez au SGBD d’expliquer la stratégie qu’il a mise en œuvre, comment il procède pour fournir le résultat du SELECT. Pour peu qu’il dise qu’il effectue des produits cartésiens, ça explique bien des choses. L’optimiseur s’explique quand on code :

EXPLAIN PLAN FOR SELECT xxx

Où xxx représente le corps de votre SELECT.

[tbc92]

Dans SQLDevelopper, tu as le champs de saisie, où tu saisis ta requête.
Au dessus de ce champs de saisise, tu as un bouton-image, avec un triangle vert, pour exécuter la requête.
A droite de ce bouton, tu as 2 autres boutons. L'un des 2 permet de lancer le fameux 'Explain plan'.

Ceci étant , in ( ) suivi d'une liste de 100 valeurs est toujours lent.
Personnellement, j'ai renoncé à ce type de requête.