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.

[vivabarça]

@tous :

Merci beaucoup pour vos réponses, je vais voir ça dès demain et je reviens vers vous pour vous dire que j'ai solutionné le problème "j'espère"

Bonne soirée

[vivabarça]

[QUOTE=vivabarça;8037934]@tous :

Bonjour,

comme convenu hier, j'ai effectué un EXPLAIN PLAN de ma requete, que j'ai montré a une personne connaissant oracle (dans mon equipe) et il ne trouve rien d'alarmant dans ce plan.
je suis revenu sur mon script pour relever le temps d'execution a l'entrée et a la sortie du script, puis au fur et a mesure j'affinais la prise de temps dans le script jusqu'a ce que j'ai trouvé la ligne qui provoque la lenteur de l'execution :
il s'agit de : oci_execute ($select); ou $select est la variable qui contient ma requete et la connection utilisée pour se connecter a la base.
je ne trouve rien sur internet sur ce type de probleme, donc si quelqu'un a une idée je suis preneur.

Merci d'avance

[fsmrel]

Bonsoir vivabarça,


C'est très bien d'avoir fait un EXPLAIN, au moins vous avez pu juger que la requête en tant que telle n’était pas responsable. Maintenant pour ce qui concerne oci_execute ($select); c’est du PHP, ça sort de mon domaine, désolé...

[mnitu]

L’instruction PHP oci_execute ne peut pas faire grand-chose d'autre que d’appeler la fonction d’interface OCI d’Oracle OCISTMTExecute. Donc vous voilà revenu à la case départ : une fonctionnalité de votre application est lente mais vous ne savez pas pourquoi ; est-ce dû au réseau, au serveur PHP, au serveur de base des données, ou autre ?
Dans ce cas le démarche à suivre est « simple » : commencez par apprendre ce qui se passe ! Il y en a plusieurs façons de faire. Dans le meilleur de cas votre application devrait vous permettre d’activer une trace SQL étendue ce qui vous permettra de tracer au niveau de la base des données ce qui se passe.

D'autre part, les informations que vous donnez sont trop génériques pour que vous puissiez avoir d'autres réponses que cellesux s’approchant des croyances mystiques « ma requête de type select * from ma vue where colonne in (1,2,3 … 100) est lente ; bah oui Oracle est lent quand il fait In avec 100 valeurs je ne le fait plus, mais je ne sais pas pourquoi».
Un plan d’exécution obtenu avec explain plan peut être parfois trompeur et ne pas correspondre à la réalité de l’exécution de la requête. Cherchez sur ce forum des réponses à d'autres problèmes d’optimisation pour trouver la démarche à suivre pour obtenir des informations nécessaires à la compréhension du plan d’exécution réel de la requête.