Discussion :

[jenesuispasunrobot]

Bonjour à tous,

j'ai fait une constatation et j'aimerais avoir votre avis sur la cause exacte de cette constatation...

une procédure stockée ne contient aucun commit. Cette procédure travaille principalement sur une table dans laquelle elle insère des lignes, lignes sur lesquelles sont effectuées plusieurs updates.

En rajoutant des commit à cette procédure j'obtiens une augmentation de performances significative.

La question que je me pose est à quoi est du exactement cette augmentation de performance ???

Oracle n'est-il pas sensé traiter les données non commitées comme les données normales ?

Merci pour vos suggestions.

[GoLDoZ]

Bonjour.
Les données non "commitées" sont stockées avant modification dans le segment UNDO. Si la quantité de données est grosse, il y a un travail d'extension du segment UNDO qui prend de la ressource.
Comme si vous faisiez un calcul compliqué et que vous deviez mémoriser toutes les étapes au lieu de ne conserver que le dernier résultat.

[jenesuispasunrobot]

Ca je l'avais bien deviné mais pour contrer cela j'ai fait le traitement une première fois pour étendre le undo.

à la seconde exécution le traitement était aussi long alors qu'il n'avait pas de extend à faire !

[fatsora]

Si tu veux voir ce que ORACLE fait exectement , ou il passe le temps d'execution c'est plutout les TRACES SQL qu'il faut faire

ou un AUTOTRACE

http://oracle.developpez.com/guide/tuning/tkprof/

[pachot]

Bonjour,
La seule explication que je vois, c'est s'il y a des indexes et que les updates modifient une colonne indexée. Parce que dans ce cas, l'ancienne entrée d'index est marquée supprimée mais subsiste jusqu'à la fin de la transaction.
Donc sans commits intermédiaires, l'index peut grossir plus.
Cordialement,
Franck.

[jenesuispasunrobot]

D'accord....

Ce cas est un peu particulier car la table est lockée. En fait il s'agit d'une table utilisée comme table temporaire dont la taille peut passer très rapidement de 10 à 100000 enregistrements.

En lockant les tables (dbms_stats.lock_table_stats()) en ayant supprimé les stats auparavant cela permet à l'optimiser de se débrouiller correctement dans la majorité des cas. Il semble cependant que lorsque l'on modifie beaucoup les données avant de réaliser des updates dessus sans faire de commit cela met l'optimiser en vrac car il continue de faire des FTS sur une table avec 20.000 enregistrements

[pachot]

Bonjour,
Le fait de committer ou pas ne peut pas changer le plan d'execution. Le plan d'execution n'est pas propre à une transaction.
Cordialement,
Franck.

[jenesuispasunrobot]

Bonjour,
Le fait de committer ou pas ne peut pas changer le plan d'execution. Le plan d'execution n'est pas propre à une transaction.
Cordialement,
Franck.

J'ai fait des tests complémentaires, le plan est le même mais le FTS alors que les modification antiérieures ont été validées prends 7 seconde alors que si les modification précédentes n'ont pas été commitées il prends 14 sec

[pachot]

Bonjour,

C'est un résultat surprenant.
Il faudrait d'abord voir ce qui est responsable de ces 7 secondes d'écart. Des stats venant de V$SQL ou mieux un tkprof permettraient de voir c'est c'est un nombre de blocks lus plus grand, par exemple.

Cordialement,
Franck.