[Theorie] Passage des informations entre les redolog et les tbs undo

Bonjour à tous,

Je suis toujours en formation oracle et j'ai une notion qui m'échappe complètement. Je n'arrive pas à comprendre la différence entre les redo-log et les tablespaces de type UNDO ou les rollback segment.

L'un comme l'autre stocke des informations d'avant/après au cas où il y'est annulation (rollback).

Si je prends un exemple concret:

Un utilisateur mets à jours 5000 lignes d'une table en remplacant la valeur type article "produit fini" par "produit semi-fini" par exemple....

Quel chemin prenne les données entre le passage de redo-log buffer, segment d'annulation et redolog files? C'est assez abstrait, pas mal d'info sur les bouquins et les sites mais tous reste trop théorique..

Ce qui me gène dans tout ça c'est que pour une mise à jours en masse qui se plante je ne serais donc pas si ça vient du redo-log buffer, database buffer ou les segments d'annulation...

D'avance merci

Les redos, comme leurs noms l'indique, c'est pour rejouer (en cas d'incident)
Les undos, c'est pour annuler les opérations.

Donc, si mon utilisateur effectue une grosse (ou pas) mise à jour, les informations avant/après sont stockée dans les redo
Dans l'undo, seules les images avant sont stockées.

Les données commitées ou non figurent dans les redos.

Quant à savoir où ça plante, l'alert.log est explicite ! ;)

merci pour ta réponse,

Peux-t'on alors dire qu'à un instant T, les valeurs "d'avant commit" se trouve à la fois dans les undo mais aussi dans le redo-log buffer?

Et que c'est seulement au moment du commit que les undo se libère et que le redo-log buffer écrit la valeur d'avant dans les redo?

Citation:

---

Envoyé par lecharcutierdelinux

Peux-t'on alors dire qu'à un instant T, les valeurs "d'avant commit" se trouve à la fois dans les undo mais aussi dans le redo-log buffer?

---

Oui, mais si ce ne sont pas les mêmes infos, on peut le dire par abus de langage dans le cadre d'update.
En insert (resp delete), seuls les redo (resp undo) contiennent les données de début de transaction.

Citation:

---

Envoyé par lecharcutierdelinux

Et que c'est seulement au moment du commit que les undo se libère et que le redo-log buffer écrit la valeur d'avant dans les redo?

---

non, les undo ne se libèrent pas comme ça (les rollback oui, par contre)
pour les undo, il faut attendre le undo_retention et/ou qu'il n'y ait plus de place dans le tablespaces, selon la garantee ou non de la rétention.
Et au moment du commit, ou du rollback, dans les redo, on écrit simplement "commit" ou "rollback".
Cela signifie que si tu as une énorme transaction annulée dans les redo, en cas de restauration, cette énorme transaction sera rejouée, même si tu sais d'avance qu'elle sera rollbackée après ! :-S
Le commit vide le redo log buffer dans les redo. Comme ça, quand tu as la réponse "commit completed", tu sais que les redos qui étaient en buffer ont été écrits, si ce n'est dans les datafile, au moins dans les redo, comme ça, en cas de crash, comme les redo seront joués, l'intégralité de ta transaction sera restaurée.

Je trouve qu'il est difficile de savoir ce qui se passe en détail car il y très peu de documentation officielle à ce niveau (y compris dans Expert Oracle), en particulier au niveau de ce qui est écrit dans le redo log. Il faut aussi savoir que les écritures dans les rollback segments (avec undo ou non) sont écrites dans les redo logs comme pour les écritures d'un segment table ou index "normal" (voir le Concepts Guide).

En cas d'erreur, Oracle doit retourne toujours un message d'erreur en général assez précis au client mais je ne crois pas qu'Oracle garantit que toute erreur soit systématiquement écrite dans l'alert.log: d'où l'importance pour le client de systématiquement tester le code retour de toutes les instructions SQL et de garder une trace de toutes les erreurs.

Merci beaucoup pour ces précisions mais si je ne suis pas sur de tout comprendre.

-> Leo:
J'ai un doute sur le fait qu'une transaction annulée soit stockées dans les redo et rejoué plus tard en cas de restauration. Je croiais que c'était justement ce qui différencie les redo des undo.

Si les 5000 update sont commités, ils sont écrit du redo-log buffer vers les redo. Les rollback segments occupés se libèrent.

SI les 5000 update son rollbackés, les undo reviennent à la place et le redo-log buffer n'écrit pas dans les fichiers redo-logs puisque cette transaction n'est pas allé jusqu'au bout. Ainsi elle n'est pas considéré comme faisant partie de l'historique des modifs de la BDD.

Enfin bon, je ne souhaite pas savoir exactement ce qui se passe mais peut on dire que c'est une définition "presque" juste?

heureusement que les annulations sont dans le redos
imagines que tu crashes ton instance avec perte de l'undo.

Les images avants, que restituera pmon lorsque des verrous seront demandés ou lorsqu'il aura le temps, ne sont par définition, qu'accessibles dans l'undo.
Et s'il est perdu, il y aurait perte d'information, ou pire, persistence de transactions en cours et non commitées.

c'est pour ça que les redo contiennent les infos undo : au recover, on regénèrera l'undo de façon à assurer la cohérence des données.
C'est dans ce sens que l'undo, pour les mises à jour contient l'avant-après : l'après, pour assurer la restaurabilité de l'undo, l'après, pour assurer la restaurabilité des données elles-mêmes.

Citation:

---

Envoyé par lecharcutierdelinux

-> Leo:
J'ai un doute sur le fait qu'une transaction annulée soit stockées dans les redo et rejoué plus tard en cas de restauration.

---

bien sûr que si !!!

si ce n'était pas le cas, tu ne pourrais pas avoir de transaction plus volumineuse que le redo log buffer.
Si j'insère 5 milliards de lignes, je ne vais pas tout garder en mémoire pour tout écrire d'un coup sur disque au commit.
Au fur et à mesure, j'écris dans les redo. et au final, j'écris si je valide ou non la transaction.

Citation:

---

Envoyé par lecharcutierdelinux

Enfin bon, je ne souhaite pas savoir exactement ce qui se passe mais peut on dire que c'est une définition "presque" juste?

---

Non, c'est totalement faux ! :oops:

Merci Leo, du coup j'avais rien compris.

Si je suis ton explication que se passe t'il si qqun passe sa journée à annuler les transactions sans apporter aucune modification à la base de données?

Les redo grossissent quand même alors que la base n'a pas changé d'un poil?

C'est fou ça, je pensais que les redo n'enregistrait que les changements à la base, au commit.

D'ailleurs c'est encore plus étrange car après les redo sont archivés, et il est donc possible comme dans l'exemple donné, de n'archiver au final aucun changement mais que des annulations!

Et oui, certes... mais la sécurité des données a un coût
la philo générale est que les opérations sont faites pour êtres validées. les rollback devant être l'exception (ce qui se traduit également par les temps de commit vs temps de rollback !)


J'ai vécu un rollback de plusieurs heures
Un commit, c'est quasi-immédiat !

Okay merci Leo.