Discussion :

[bstevy]

Bonjour,


Je repose ici un problème que j'avais posé en SQL mais qui est intrinsèquement lié au fonctionnement PLSQL.

Ce que je cherche à savoir, c'est si la charge de travail effectuée par un rollback change si dans une transaction on effectue un ou plusieurs update.

Voici mon cas. (je vous l'ai simplifié donc on évite les remarques du genre : c'est idiot de faire tout ça pour si peu)

J'ai une table "extraction" dans laquelle j'ai des numéros de contrat et un flag "A_extraire" 0 ou 1.
Je sélectionne tous mes contrat where A_extraire=1 et je mets ça dans un curseur
Je loop sur mon curseur
Je test si mon contrat existe dans ma base.
- S'il n'existe pas, je raise une exception : Batchabort
- S'il existe, j'update ma table extraction en mettant "A_extraire"=0
Fin de ma boucle.
Je commit (seul point de commit du script)

Exception Batchabort
- rollback (rollback manuel, il n'est pas question de rollback parce que l'update aurait planté.)
- exit

->Dans ce cas, je suis donc amené à faire un rollback sur n update que j'ai fait précédemment.
De ce que j'ai vu dans la doc,

•Undoes all changes made by all the SQL statements in the transaction by using the corresponding undo segments

The transaction table entry for every active transaction contains a pointer to all the undo data (in reverse order of application) for the transaction. The database reads the data from the undo segment, reverses the operation, and then marks the undo entry as applied. Thus, if a transaction updates a row, then a rollback reverses the update.

Mais je ne trouve pas ca très clair. Est ce que mon rollback va effectuer un reverse je dirais global, c'est à dire, il va inverser tous les updates en même temps, ou alors il va inverser le dernier update, plus l'avant dernier... etc, tout ça en mode séquentiel, extrêmement lent ?




Je voudrais au final comparer ce mode d'exécution, avec un mode où je ferais plutôt la chose suivante :

J'ai une table "extraction" dans laquelle j'ai des numéros de contrat et un flag "A_extraire" 0 ou 1.
Je sélectionne tous mes contrat where A_extraire=1 et je mets ça dans un curseur
Je mets à jour ma table avec "A_extraire"=0
Je loop sur mon curseur
Je test si mon contrat existe dans ma base.
- S'il n'existe pas, je raise une exception : Batchabort
Fin de ma boucle.
Je commit (seul point de commit du script)

Exception Batchabort
- rollback (rollback manuel, il n'est pas question de rollback parce que l'update aurait planté.)
- exit

A peu près la même chose que précédemment, sauf que je n'ai qu'une seule opération d'update.

Et donc, d'un point de vue journalisation, comment est-ce que c'est enregistré pour Oracle cette opération par rapport à la précédente ?
est-ce que l'on va journaliser la ligne de la table, et donc dans ce cas, le cas 1 et le cas 2 auront à peu près la même procédure de rollback
Ou est ce qu'on va journaliser l'opération, à savoir donc l'update, et revenir d'une opération à la précédente et donc on risque d'exploser les temps de traitements.



Dans la même idée, si j'ai un enregistrement A, que je l'update en B, et que j'update encore en C, et que je rollback,
est ce que ca fait directement C devient A ou est ce que ca refait dans l'autre sens C devient B et B devient A ?


Merci à ceux qui pourront répondre à toutes ces questions.

Et si c'est confu, je peux expliquer d'avantage, hésitez pas à me demander.

[mnitu]

Bonjour,


Je repose ici un problème que j'avais posé en SQL mais qui est intrinsèquement lié au fonctionnement PLSQL.

Ce que je cherche à savoir, c'est si la charge de travail effectuée par un rollback change si dans une transaction on effectue un ou plusieurs update.

....

Non la notion de rollback est intrinsèquement lié à la notion de transaction qui est perpendiculaire au langage utilisé.
Une ou N instruction SQL modifiée M enregistrements d'une table. Ces modifications sont enregistrés dans les segments d'undo. Rollback signifie simplement annuler les modifications faite sur les données peu importe le nombre des instructions SQL qui y ont contribuées.
De la même façon modifier la même enregistrement N fois implique sauvegarder N copies des données modifiées. Dans ce cas rollback implique appliquer toutes ces modifications en ordre inverse.

[Mohamed.Houri]

Bonsoir

Pourquoi ne pas utiliser un savepoint et un rollback to savepoint avec un seul commit et un rollback uniquement des contrats non extraits ou en erreur. quelque chose qui ressemble à ceci:

https://hourim.wordpress.com/?s=rollback+to+savepoint

où j'ai résumé comment je faisais pour traiter ce genre de situation

Sinon, effectivement un rollback applique dans le sens inverse toutes les modifications faites à un bloque de données grâce au redo vecteur (contenant les undos)

Savez-vous aussi quelle est la dernière instruction d'un rollback? réponse : commit :-)

Bien à vous

[bstevy]

@mnitu
Et bien, on y arrive enfin. Là, au moins, c'est clair, et j'ai compris ^^
Donc, l'idée, c'est bien que d'un point de vue transaction, je peux rester sur mon mode de fonctionnement unitaire, ou je fais plusieurs update. ca n'aura pas d'influence à ce niveau là de changer en une seule grosse requête d'update. Par contre, on est d'accord sur le fait qu'un seul update sera toujours plus rapide que plein de petits.



@Mohamed.Houri
La question n'est vraiment pas d'optimer le traitement, je connais déjà les pistes d'optimisation. Ce que je cherche à savoir, c'est sur les différentes partie que je peux optimiser, est ce que le gain est important, négligeable ou nul. C'est pour ca que ma question porte véritablement sur le nombre d'étape qui va être réalisés par la base pour rollback le cas 1 ou le cas 2. Or la, ca ne semble pas changer grand chose.
Mais merci quand même pour cette idée

[mnitu]

...
Pourquoi ne pas utiliser un savepoint et un rollback to savepoint avec un seul commit et un rollback uniquement des contrats non extraits ou en erreur. quelque chose qui ressemble à ceci:

https://hourim.wordpress.com/?s=rollback+to+savepoint

où j'ai résumé comment je faisais pour traiter ce genre de situation
...

Je suis persuadé que vous pouvez écrire quelque chose de mieux que ce type de code. Sinon pas mal de mauvaises habitudes desquelles à priori vous est conscient :

• When Others sans Raise
• When Others Then ... Raise;
• Update ligne à ligne
• Boucle curseur implicite

Bref si c'est juste pour dépanner on s'en sort mais...

[bstevy]

A non, mais comme je l'ai dit, ce n'est absolument pas pour corriger mon code que je suis là
Je suis parfaitement conscient qu'il est pourri, mais le truc, c'est qu'il est pas de moi.

Je suis en train de dépoussierer des requêtes qui date de 1999 et qui sont toujours utilisées... et c'est vraiment pas joli.
Mais c'est des fonctions qui sont utilisées quotidiennement sur des opérations assez critique, donc je ne peux pas me permettre de tout modifier comme ca. Il faut que je justifie chaque opération et qu'elles soient approuvées en commité. Je vous raconte même pas la galère. Vive le Japon lol




pour info, mnitu, t'as vu mon poste sur un mega update qu'ils veulent faire... puisque tu as bien trollé dessus... et le fait qu'ils veulent mettre en place la solution 2, genre, juste le pire du pire, prouve l'état d'esprit dans lequel je travaille. Il font du sql comme on ferait de l'assembleur, ca me fait au coeur moi qui vient de teradata...