Commit sur un grand nombre d'update
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)
Citation:
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,
Citation:
•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 :
Citation:
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.
