Discussion :

[hoaxpunk]

bonjour,

voila j'ai a fait un update pour passé tous les mail en lower :

Code :

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

Update client set cli_mail = lower(cli_mail);

j'ai 54 mail a updaté, et dans toad la requete dure au moin 3 ou 4 minutes (j'ai abandonner a chaque fois pour trouver une autre solution)

et je supose que 3 ou 4 minutes c'est beaucoup trop...donc probleme!

je supose qu'il boucle en metant a chaque fois en minuscule, les mail qu'il a deja parcouru, donc n'y a t'il pas une facon soit :
1 - de limiter au nombre exacte d'enregistrement l'update
2 - de modifier uniquement les mail qui contiennent deja des majuscule(quel test???)


merci de votre aide

[Yanika_bzh]

Tu n'as pas des triggers présents concernant cette colonne ?

Car je viens de faire un test sur Toad, la meme fonction mets a jour 88 enregistrement en moins de 80 ms !

Avant de trouver une solution a ton probleme, tu devrais essayer de trouver la cause du probleme, car tu risques de repousser ton souci et de le voir reapparaitre plus tard et ca peut etre encore pire.

regardes la taille de tes rollback segments.

En tout cas, ce n'est pas un probleme SQL, tu devrais poster cela dans ORACLE (je suppose que c'est oracle puisque tu parles de TOAD). Tu auras surement des reponses pour t'orienter dans la recherche de la cause de ton probleme.

Bon courage

[Wurlitzer]

j'ai 54 mail a updaté, et dans toad la requete dure au moin 3 ou 4 minutes (j'ai abandonner a chaque fois pour trouver une autre solution)

Tu as 54 mails à updater mais combien de ligne dans ta table client ? Comme tu n'a pas de condition sur ton update tu lis toute la table client meme si tu n'as que 54 mails a mettre a jour. Si elle fait des millier de ligne cela peut etre long.

Hope this helps

[nuke_y]

Je suis assez d'accord, le fait qu'il n'y ait pas de clauses WHERE m'étonne. C'est une base de test ?

[dyvim]

Tu as 54 mails à updater mais combien de ligne dans ta table client ? Comme tu n'a pas de condition sur ton update tu lis toute la table client meme si tu n'as que 54 mails a mettre a jour. Si elle fait des millier de ligne cela peut etre long.

Tout à fait d'accord...
La solution pourrait être quelque chose comme çà:

Code :

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

1
2
3
Update client 
set cli_mail = lower(cli_mail)
where cli_mail != lower(cli_mail);

[Jaouad]

Bonjour ,
par curiosité à quoi sert d'avoir une condition de ce type là :

Code :

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

1
2
 
where cli_mail != lower(cli_mail);

Pour ma part elle ne reinstreint pas les lignes concernés et fait également un FTS.

Que donne l'explain plan , le nombre de lignes totales et surtout les évènements d'attentes. Il se peut que cette table soit accédés en même temps que toi !!

[dyvim]

Vu l'update qui est fait:

Code :

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

set cli_mail = lower (cli_mail)

j'en déduit que le format standard est en minuscule et que donc les lignes à updater sont toutes celles qui ne sont pas encore en minuscule...
D'ou la clause :

Code :

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

where cli_mail != lower(cli_mail)

ce qui évitera d'updater toutes les lignes (peut être seulement 50 sur 2000000 pourquoi pas) mais n'évitera pas le full_table_scan.

Autrement dit Oracle se tapera bien toute la table pour trouver les lignes qui ne sont pas au bon format mais ne remontera en mémoire que les 50 lignes à modifier. (alors que sans la clause, il remontera toute la table en mémoire puisqu'il modifiera toutes les lignes).

Pour moi les deux plans d'exécution ne devraient pas être les même.(j'avoue que je n'ai pas eu le temps de vérifier)

Voilà l'interêt que je vois mais peut être que je me suis dans l'erreur concernant le fonctionnement du moteur d'Oracle.

Cette réflexion se base sur un exemple concret que j'utilise souvent sur une table de 500 000 lignes (cmf). le second des deux update suivants est en général beaucoup plus rapide que le premier.

Code :

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

1
2
3
update cmf set acct_seg_id =10
 
update cmf set acct_seg_id = 10 where acct_seg_id <>10

Le mieux étant sans doute de formater toutes les insertions en lower mais si les incohérences sont déjà présentes la seule solution est d'updater les lignes.

Sinon effectivement des verrous pouraient expliquer la lenteur

[orafrance]

s'il y a des indexes et que le nombre de lignes à mettre à jour est important, il peut être intéressant de dropper l'index avant l'update et le recréer après aussi

[Jaouad]

Cette réflexion se base sur un exemple concret que j'utilise souvent sur une table de 500 000 lignes (cmf). le second des deux update suivants est en général beaucoup plus rapide que le premier.

Code :

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

1
2
3
update cmf set acct_seg_id =10
 
update cmf set acct_seg_id = 10 where acct_seg_id <>10

Le mieux étant sans doute de formater toutes les insertions en lower mais si les incohérences sont déjà présentes la seule solution est d'updater les lignes.

Alors je ne suis pas du tout d'accord , dans le premier cas la requête devrait à mon avis faire un FTS sur toute la table et ne pas passait par l'index, car une lecture de toute les valeurs de la colonne est nécessaire pour les passer en lower avant la comparaison.

Dans ton second exemple, l'index B-Tree ( nous prendrons cette exemple) va déterminer grace au rowid toute les valeurs stockés dans l'index et différent de ta valeur.

Donc si nous en savons pas plus sur la cardinalité des colonnes, on ne peut pas comparer les deux exemples.