Posté le: Mar Mai 18, 2004 15:44 Sujet du message: Redo logs, Rollbacks segments, Datafiles, SGA, SOS !
--------------------------------------------------------------------------------
Bonjour à tous
DBA débutant, je me pose une question de fond ...
Malgré toutes mes lectures sur le sujet, je n'ai pas trouvé d'explication schématique simple et claire permettant de comprendre PRECISEMENT, à l'aide d'un EXEMPLE tel que ci-dessous, ce qui se passe en mémoire SGA, dans les fichiers de journalisation, les fichiers de données et les segments d'annulation lors d'une transaction simple avec rollbacks et commits, avec panne ou sans panne.
Exemple :
1. UPDATE facture SET ttc = ht * 1.1;
2. ROLLBACK;
3. UPDATE facture SET ttc = ht * 1.2;
4. COMMIT;
Contenu de la table avant l'étape 1 :
N° FACTURE HT TTC
--------------- -- ---
1 10 -
2 20 -
3 30 -
Que se passe-t-il à chaque étape dans les mémoires / fichiers cités ci-dessus (SGA, redo log, rollback, datafile) ? Quel est leur CONTENU à la fin des étapes 1, 2, 3 et 4 :
- si aucune panne
- si panne pendant la transaction 1
- si panne pendant le rollback 2
- si panne pendant la transaction 3
- si panne pendant le commit 4.
Quelqu'un connaîtrait-il une doc PRECISE sur ce point, un bouquin, un site Web ?
Merci par avance, je crois que cela éclaircirait beaucoup les principes, car un bon exemple vaut souvent mieux qu'un long discours ...
_________________
Jack.
Revenir en haut
helyos
Redacteur (Oracle)
Inscrit le: 15 Mai 2003
Messages: 876
Localisation: Oracle Inside
Posté le: Mar Mai 18, 2004 15:54 Sujet du message:
--------------------------------------------------------------------------------
Oula alors je vais essayer de t'expliquer calmement (je passe ici les explications sur les verrous sinon je t'écris un bouquin)
Au premier update
Oracle vérifie la syntaxe de ta commande
Si oui il enregistre la transaction dans les redo logs
Ensuite si les blocs sont pas présent en mémoire il les prends sur le disques et les ramenes en mémoire SGA
La il crée les images avant des blocs (avant modifs quoi qui sera utilisée par les autres user.) qu'il stocke dans les rollbacks segments et créer une image apres de bloc (celle avec laquelle tu vas travailler)
Ensuite pour ton rollback
Oracle ecris la fin de transaction dans les redo logs
Efface les images apres correspondant à la transaction
Remet les images avant comme étant la bonne version
2 eme update
Meme chose que le premier
Commit
Oracle utilise un procédé le FAST COMMIT
C'est à dire que la premiere chose qu'il fait est qu'il ecris le commit dans les redo logs, comme ca si ca plante c'estplus grave car smon sera en mesure de relire les redo logs et de rejouer les données meme si elles sont pas écrites sur le disque.
Une fois le commit enregistré, Il efface les images avant, et dis que les images apres sont les nouvelles versions des blocs
Si y a panne pendant 1 bah c'est pas tres grave car smon rejouerea les transactions contenues dans les redo log et comme celle ci ne sera pas validée il rollback la transaction
Pareil pour le 2
Pareil pour le 3
Si ca plante pendant le commit, a cause du fast commit il est pratiquement impossible de plante avant que le commit soit enregistré dans les redo log donc ca plante apres, donc les blocs sont pas ecris sur le disque
C'est pas grave car notre pote smon se chargera de rejouer la transaction pour nous et de regenerer notre derniere version des donness
J'espere que j'ai été assez clair...
--------------------------------------------------------------------------------
on peut ajouter que tous les x temps (ne rentrons pas ds les détails) , le database writer écrira les données modifiées (commitées ou non) dans les datafiles
je te suggère de lire le Concepts Guide chapitre 1 ! tu auras un super schéma
Revenir en haut
orafrance
Membre Expert(e)
--------------------------------------------------------------------------------
Marc Musette a écrit:
on peut ajouter que tous les x temps (ne rentrons pas ds les détails) , le database writer écrira les données modifiées (commitées ou non) dans les datafiles
je te suggère de lire le Concepts Guide chapitre 1 ! tu auras un super schéma
Tout à fait ceci étant du à l'évolution de l'occupation de l'espace disponible en mémoire, au nombre de Dirty Blocs et aussi aux différents parametre de DBWn
c'est pour cela que la premiere chose à être enregistrée est la transaction car les fichiers de données peuvent contenir des informations non valides à un instant T dans le temps et que les informations sur la transaction seront nécessaire lors de la synchronisation des données.
Ps : merci orafrance
_________________
Oracle C'est trop fort pour toi
EN PASSANT OUBLIEZ PAS LE BOUTON [Résolu] et les balises [ code ]
Mes articles(Les Lobs, Flashback, Logminer)
Revenir en haut
jack554
Invité(e) régulier(ère)
Inscrit le: 14 Fév 2003
Messages: 28
Posté le: Mar Mai 18, 2004 16:36 Sujet du message:
--------------------------------------------------------------------------------
Ok c'est vraiment sympa.
Déjà 3 questions :
1) L'image après est-elle bien créée aussi dans les RBS, comme l'image avant ?
2) Dans tout le processus je ne vois pas quand les données modifiées sont écrites réellement dans les datafiles ?
3) Dans ta phrase
Citation:
Ensuite pour ton rollback
Oracle ecris la fin de transaction dans les redo logs
qu'entends-tu par "fin de transaction" ?
_________________
Jack.
--------------------------------------------------------------------------------
Alors question 1
Non l'image apres est stockée en mémoire pour des questions de tuning (jusqu'a temps que DBWn l'écrive sur le disque si y a besoin de place en mémoire)
Question 2 voir au dessus
Question 3 fin de transaction = COMMIT ou ROLLBACK (attention aux ordres DDL (create, alter, grant..) qui sont autocommité)
_________________
Fonctionnement simplifié d'une transaction Oracle
), j'ai essayé de résumer dans un document le fonctionnement d'une transaction Oracle du point de vue des rollback segments, redo logs, fichiers de données et mémoire SGA.
Répondre avec citation
Envoyé par jack554
Partager