Bonjour,
jaimerais bien comprendre la difference entre des finchier REDO organisé en
undo ou organisé en rollback segment ( dans oracle 9i),
merci,
Version imprimable
Bonjour,
jaimerais bien comprendre la difference entre des finchier REDO organisé en
undo ou organisé en rollback segment ( dans oracle 9i),
merci,
Attention, le REDO c'est ce qui passe dans les online redo logs puis dans les archive redo logs et le UNDO ce c'est qui est stocké dans les rollback segments.
Configurer la base en mode undo automatique revient a déléguer à Oracle la création des rollback segments et leur gestion (nombre d'extents, agrandissement, réduction de taille, etc.): le DBA doit essentiellement définir le tablespace et la durée de rétention (undo_retention). Le mode manuel c'est le mode par défaut où le DBA doit décider de créer et gérer lui même les rollback segments ainsi que le tablespace.
Voir le Concepts Guide.
Bonjour,
[Pour faire simple et sans rentrer ds les détails]
Attention, les redo n'ont rien à voir ni avec les rollback ou les undo segments. Les redo (redo logs) sont les fichiers qui contiennent pour dire simplement toutes les modification faites dans l'instance au cours de sont fonctionnement. Ils font partie de l'aspect cohérence de l'instance/base en cas de crash/recovery de façon à revenir à un état stable (transactionnellement parlant) au redémarrage.
Les rollback et undo sont les éléments principaux qui permettent d'avoir l'image avant des modifications de façon à assurer le cohérence transactionnelle. Grosso merdo (mais ce n'est pas le seul cas), un user us1 modifie la valeur va1 de X lignes d'une table sans pour autant commiter. Un autre user devra voir la valeur va1 avant la modification de ce user. Oracle va aller ds les rollback et/ou undo segment pour avoir la valeur avant et la donner au second user.
Quant à la différence entre redo et rollback, les rollback sont les mécanismes originels d'Oracle. L'admin devait positionner lui même le nombre et la taille des rollback de façon que l'information image avant ds les rollback soient présentent en cas de besoin (par le user2 par ex). Sinon, on récupérait le falmeux ora-1555 snapshot too old indiquant au user2 que lon avait plus l'information avant et que par conséquent on ne pouvait pas répondre favorablement à sa requête. Il y a plein de doc ds metalink qui donnait des règles pour dimensionner les rollback.
Les undo segment sont les mecanismes remplacant les rollback ds les versions récentes d'Oracle. La partie admin est passé au moteur Oracle. On précise simplement en seconde (undo_retention), la durée pdt laquelle Oracle doit garder l'image avant d'une données pour de futurs besoins avant de la perdre ainsi que le tablespace d'undo de l'instance. Cela limite grandement l'arrivées des ORA-1555 (sans toutefois les supprimer complètement malgrès l'imagnaire populaire !). A vous simplement de positioner undo_retention. Le Grid Control a un outil permettant de tuner cela. En théorie, undo_retention devrait être au moins aussi gd que la plus longue des transaction mais ... ds ce cas je connais des cas ou le tbs d'undo a explosé ... Il faut trouver un juste compromis entre les besoins fonctionnels et l'espace de stockage des undo (entre autre).
Cdlt
Hieraklion
Ok , j'ai tres bien compris ,
merci beacoup pour vos réponse chirurgicale !
A+