[9i] Performance requete UPDATE + IN

Bonjour,
je travaille sur la requete suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 UPDATE FICHE SET IND_RAPPELECHU = ? WHERE ID_FICHE IN (SELECT F.ID_FICHE FROM FICHE F, CLIENT C WHERE F.DATERAPPELPROACTIF < SYSDATE AND (F.ETAT = ? OR F.ETAT = ?) AND F.ID_PROCESSUS = ? AND F.NUMCLIENT = C.NUMEROCLIENT AND C.ID_CENTRE = ?)
Ma table FiCHE et ma table CLIENT sont des tables volumineuses pouvant contenir plusieurs millions d'enregistrements.
Les temps de réponses de cette requete ne sont pas satisfaisants.
Je cherche à les améliorer.

Quelqu'un a-t-il de sidées à me soumettre. Je travail sous oracle 9i.

Merci d'avance

Mise en forme effectuée par Magnus. Merci d'y penser à l'avenir :wink:

Vous pouvez essayer d'activez la trace SQL et d'utiliser tkprof (http://oracle.developpez.com/guide/tuning/tkprof/) pour voir le plan d'exécution. Postez les résultats avec:
- le DDL de création des tables et des index
- la façon dont vous calculez les statistiques sur les objets concernés.

Il faut toujours préférer le EXISTS dans ces cas là:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
UPDATE FICHE U
SET    IND_RAPPELECHU = ?
WHERE  EXISTS (
       SELECT 1 FROM
                           FICHE F,
                           CLIENT C
                    WHERE  U.IF_FICHE = F.ID_FICHE
                           AND F.DATERAPPELPROACTIF < SYSDATE
                           AND (F.ETAT = ?
                                 OR F.ETAT = ?)
                           AND F.ID_PROCESSUS = ?
                           AND F.NUMCLIENT = C.NUMEROCLIENT
                           AND C.ID_CENTRE = ?)

voir même:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
UPDATE FICHE U
SET    IND_RAPPELECHU = ?
WHERE  EXISTS (
       SELECT 1 FROM
                           FICHE F                           
                    WHERE  U.IF_FICHE = F.ID_FICHE
                           AND F.DATERAPPELPROACTIF < SYSDATE
                           AND (F.ETAT = ? OR F.ETAT = ?)
                           AND F.ID_PROCESSUS = ?
                           AND  EXISTS (
                                SELECT 1 FROM CLIENT C
                                    WHERE   F.NUMCLIENT = C.NUMEROCLIENT
                                              AND C.ID_CENTRE = ?)
                          )

ça c'est pour le principe, ensuite il y a les classique de l'optimisation à savoir:
- Passer le calcul de stats oracle
- vérifier que les critères les plus discriminant portent bien sur des colonnes indexées
- vérifier que les colonne de jointure sont bien indexées.

Citation:

Envoyé par remi4444

Il faut toujours préférer le EXISTS dans ces cas là

Attention à de la généralisation trop hâtive. J'ai vu sur le site de Tom des cas où le in était plus performants :
http://asktom.oracle.com/pls/ask/f?p...D:953229842074

Il n'y a pas de règles toutes faites pour optimiser une requête, il n'y a QUE le plan d'éxécution et le tkprof qui permettent de l'optimiser.

J'admet que j'ai dégainé le mot "toujours" un peu vite...
Ca fait tellement longtemps que je fais une campagne de promotion des "EXISTS" que je m'emporte un peu vite... J'aurais du dire, qu'il faut à priori préferer le EXISTS quand on veux faire du filtrage. Le IN est dangeureux pour moi car il peut masquer des gaspillage ennormes de resources (un produit cartésien par exemple). Mais je suis d'accord avec toi, ce ne sont que des discussions de principe, il faut dans tous les cas s'interresser au plan d'exécution (apres passage de stats) pour compendre ce qui se passe...

Dommage ton lien ne fonctionne pas, ça m'interresse de savoir quel cas on peut trouvé pour que IN soit meilleur...

Voici un lien sur le sujet qui doit marcher: http://asktom.oracle.com/pls/ask/f?p...A:953229842074

pour résumer simplement, si le contenu de IN permet de limiter fortement le nombre de ligne ramener ou de passer par un index très performant alors IN est favorable... mais c'est pareil... j'aime beaucoup EXISTS... et encore plus NOT EXISTS :)

Citation:

Envoyé par Fred_D

j'aime beaucoup EXISTS... et encore plus NOT EXISTS :)

Ca n'a pourtant pas été toujours ton discours :
http://www.developpez.net/forums/sho...40&postcount=5

Citation:

Envoyé par Fred_D

pour résumer simplement, si le contenu de IN permet de limiter fortement le nombre de ligne ramener ou de passer par un index très performant alors IN est favorable... mais c'est pareil... j'aime beaucoup EXISTS... et encore plus NOT EXISTS :)

Même avec un EXISTS, si le CBO trouve qu'un index réduit fortement le nombre de lignes, il fera le plan adapté en "remontant" le chemin...

Je suis d'accord avec toi, j'aime encore mieux les NOT EXISTS (préférés à priori aux très risqués NOT IN) et surtout je fait une grosse alergie sur les DISTINCT.
D'ailleurs je vais peut etre monté une association pour la repression des DISTINCT et la promotion des EXISTS ;)

Citation:

Envoyé par remi4444

et surtout je fait une grosse alergie sur les DISTINCT.

C'est comme tout, il faut les utiliser à bon escient uniquement ;) Malheureusement, ce n'est pas toujours (souvent) le cas :?

Moi je montrerai bien un association contre les "select count(*)" excutés pour savoir s'il existe au moins un enregistrement correspondant à la clause where ;)

J'adhère aux 2, et je créerai celle des Anti "EXISTS ( SELECT client...)"
:mouarf:

Citation:

Envoyé par plaineR

Ca n'a pourtant pas été toujours ton discours :
http://www.developpez.net/forums/sho...40&postcount=5

j'ai dit que j'aimais bien, pas que c'était à utiliser tout azimut ;)

Citation:

Envoyé par Fred_D

j'ai dit que j'aimais bien, pas que c'était à utiliser tout azimut ;)

OK. Je me demandais juste ce qui justifiait ton éventuel changement d'opinion ;)

Sur cette dernière remarque, je suis d'accord avec toi, et c'était l'objet de mon premier post, il faut réfléchir avant d'écrire une requête et ne pas appliquer des règles "toutes faites" ni avoir des a-priori ;)