Discussion :

[tommey]

Salut, j'ai un problème.

J'ai une requête du genre :

Code :

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

1
2
3
4
5
6
7
 
SELECT DATA.*
        FROM (
                 SELECT rownum "ZEROWNUM", TABLE_1.* FROM TABLE_1
                  WHERE ....
                   and rownum < 1000) DATA
WHERE ZERONUM >= 1

Et je dois ajouter la clause FOR UPDATE à la fin met je pogne le orracode ORA-02014.

Ce que je dois faire c'est de parcourir 1000 enregistrement et décider si je dois faire une mise à jour sur un enregistrement ou non, ensuite récupèrer les 1000 prochains...ainsi de suite jusqu'à ce qu'il n'y en est plus.

Je fais cette appel en JAVA et c'est une question de performance...

On ne veut pas bloquer 100 000 enregistrement non plus avec la clause for update.

Des solutions/contournements/propositions?


Merci beaucoup de votre habituelle collaboration.

[star]

Quelle version Oracle ?

.

[mnitu]

Oui, ça doit être une question de performance parce que votre algorithme n’est pas parti pour. Il est toujours plus cher de ramener et filtrer les enregistrements dans la partie client que de la faire sur le serveur.

Donc un traitement optimal est Update … Set … Where …

Concernant votre souci vous pouvez contourner ce problème si vous constituez vos lots de mille enregistrements en utilisant des autres critères que le RowNum.

[tommey]

Je sais que le update...set..where serait mieux.

Mais je dois récupèrer mes milles contacts, les passer dans un web service et ensuite décider de peut-être en updater seulement 10 sur les 1000.

Merci pour le rownum, ça semble effectivement être la cause du problème.

Pourquoi vous dites que ça serait pas performant?

[mnitu]

Je sais que le update...set..where serait mieux.

Mais je dois récupèrer mes milles contacts, les passer dans un web service et ensuite décider de peut-être en updater seulement 10 sur les 1000.

Merci pour le rownum, ça semble effectivement être la cause du problème.

Pourquoi vous dites que ça serait pas performant?

Prenons votre exemple. La table a 100 000 enregistrements, que vous décidez de traiter par lot de 1000, cela fait 100 lots. Disons qu’en moyenne vous mettez à jour 10 enregistrements par lot cella fait 1 000 enregistrements à mettre à jour. Que ‘est que vous pensez que va coûter plus cher, faire un update des 1000 lignes dans la base ou chercher et transférer par le réseau 100 000 enregistrements pour les filler à un Web-Service pour éliminer ensuite 99 % ?

La règle d’or de l’optimisation : il est toujours plus performant de ne rien faire que de faire pour rien !

Essayez donc d’avoir une autre approche pour ce problème.

[tommey]

Je vais regarder ça avec mon architecte.

Merci!