LBD - C.

Vangenot 21 avril 2005

Ingnierie des Bases de Donnes Rfrence

Database systems
Fiabilit
The complete book, chapitre 17
Garcia-Molina, Ullman, Widom

Fiabilit (Reliability/Recovery/Resilience) Fiabilit

Capacit du systme SGBD remdier aux erreurs
et pannes
Erreurs dans les programmes dapplication
(transactions)
Erreurs dans lentre des donnes
Erreurs denregistrement sur disques et crash matriels
Catastrophes
Fiabilit= capacit restaurer la base de
donnes dans un tat connu comme correct
aprs une erreur quelconque qui a amen la
base de donnes dans un tat non correct.
Objectifs:
viter que la BD soit incohrente
viter que les pg donnent des rsultats faux

Dfaillances systme Diffrents types de pannes/erreurs peuvent

induire un tat incorrect de la BD
3 4

Erreurs dans lentre des donnes Erreurs disques

Erreurs dtectables : Dtection de l'erreur: Utilisation des bits de parit pour

vrifier les enregistrements au niveau secteur
par les contraintes dintgrit
Solutions proposes en cas de crash de la tte de
par les triggers


lecture : Redondance
Erreurs non dtectables : 1) RAID: "Redundant Arrays of Independent Disks"*
RAID niveau 1 : mirroring (doublement des disques)
valeurs vraisemblables mais incorrectes RAID niveau 4 : un seul disque miroir avec les bits de parit de tous
les disques et du disque miroir
(par exemple, anne de naissance 1978 au RAID niveau 5 : le disque miroir est rparti
lieu de 1987) 2) Archivage
3) Plusieurs BD rparties avec duplication (copies multiples)

5 * chapitre 11 du livre: Database systems, the complete book 6

Cours Ingnierie des bases de donnes 1

LBD - C. Vangenot 21 avril 2005

Catastrophes Dfaillance systme

Dfaillances systme: pannes/erreurs qui
Exemple:

entranent la mauvaise excution d'une

Incendie, inondation, explosion, ... transaction et donc BD incohrente
destruction des donnes Exemples les plus courants:
Pannes (bugs, coupure courant) et erreurs de logiciel

Problmes:
Solution: Redondance Perte ou altration du contenu de la mmoire centrale
En particulier, perte de linformation sur les transactions en
1) Copies darchive cours
2) BD rparties avec duplication (copies Solution:
multiples) Journalisation + Procdure de reprise aprs panne

7 8

Programmes Transactions Gestion des transactions / fiabilit

Transaction = unit de programme excute sur SGBD
Dbut Transaction
Accs la base de donnes (lectures, critures)
Calculs en mmoire centrale
Fin Transaction : COMMIT ou ROLLBACK
Une transaction s'excute correctement
si:
Atomicit (+ cohrence, isolation, durabilit)
tout ou rien
Gestionnaire de la fiabilit doit s'assurer que
cette atomicit est maintenue lors de pannes.

Commit : excution correcte validation

Rollback : excution incorrecte effacement

9 10

Transfert des donnes Interaction transactions - BD

3 espaces de stockage:
Le transfert de donnes transaction <-> disque Disque (BD)
Zone de mmoire centrale (gre par le gestionnaire des Buffers)
de la BD transite par des tampons (buffers) :

Zone de mmoire rserve pour la transaction

gestionnaire des Buffers
lecture
Disque
Unit de transfert en entre/sortie: un bloc
criture
disque Mmoire Buffers
transaction
Mmoire Ecriture:
centrale Buffer pas forcment copi sur
disque tout de suite, peut rester en
mmoire (dangereux), dcid par BM
Une des tapes du processus de fiabilit
est de FORCER le BM d'crire les donnes
11 sur disque 12

Cours Ingnierie des bases de donnes 2

LBD - C. Vangenot 21 avril 2005

Transfert de donnes: Gestionnaire des

transactions Operations primitives:
Gestionnaire
Activ en cas de problme,
Gestionnaire de la examine le LOG et rpare les Input (x): block contenant x mmoire
des requtes fiabilit donnes BM
(QP) (RM) Output (x): block contenant x disque
(et LM)
Excution des Input Read (x,t): faire input(x) si ncessaire
requtes Gestionnaire Output
des buffers
Gestionnaire
"copy log" Donnes t valeur de x
(BM)
des Transactions
transactions (TM) log records "copy log"
LOG Write (x,t): faire input(x) si ncessaire
TM: - S'assure que les transactions t x (en mmoire)
s'excutent correctement. Gestionnaire
- Gre la concurrence.
des journaux
- Indique quand possible ou ncessaire
de copier les donnes sur disque et (LM)
dans le LOG 13 14

T
Exemple A:=A*2
Exemple - suite
B:=B*2
Action de T v M.A M.B D.A D.B Que faire ?
8 8 Remettre A et B valeur initiale: 8
1) Read (A,v) 8 8 8 8 Mettre B 16
2) v := v*2 16 8 8 8
3) Write (A,v) 16 16 8 8
Comment?
4) Read (B,v) 8 16 8 8 8
5) v := v*2 16 16 8 8 8
6) Write (B,v) 16 16 16 8 8
7) Output (A) 16 16 16 16 8
BM
8) Output (B) 16 16 16 16 16 Panne
15 16

Solutions Le journal (log)

Journalisation (sur support non volatile) de Squence d'enregistrements de LOG

T1 T2 T3 T4
lactivit des transactions : LOG
Objectif: s'assurer que du point de vue de la BD l'atomicit
est respecte Enregistre les actions de toutes les transactions, Append only
Trois types de journalisation
Les enregistrements sont en mmoire centrale comme les
UNDO

donnes de la BD et sont crits priodiquement sur disque.
REDO
UNDO/REDO Commande FLUSH LOG permet de forcer la copie du contenu du
Log de la mmoire centrale sur le disque
Procdure de reprise aprs panne En cas de panne, log est utilis:
"Recovery": reconstruction de la BD partir du LOG soit pour annuler des actions faites par transactions UNDO
soit pour refaire des actions faites par transactions REDO
"Checkpointing": limite la taille du LOG


soit pour annuler certaines actions et refaire d'autres UNDO/REDO
Archivage: restauration de la BD mme aprs grosses pannes
17 18

Cours Ingnierie des bases de donnes 3

LBD - C. Vangenot 21 avril 2005

Le journal (log) Techniques de reprise (recovery)

Articles de diffrents types : UNDO

<Start T>
dfait laction des transactions non valides*


<Commit T>
<Abort T> REDO (deferred update)
<T, X, v > refait laction des transactions non valides
signifie: Transaction T a mis jour lment X.
o X: lment mis jour, v: ancienne valeur de X UNDO / REDO (immediate update)
<T, X, v> est gnr par un WRITE dfait ou refait suivant ltat de la transaction
(pas par OUTPUT donc pas encore forcment sur disque)

19 *transaction valide= transaction ayant fait un Commit 20

Rgles de journalisation UNDO Rgles de journalisation UNDO (2)

U 1) crire les mises jour <T,X,v> dans le Signifie que on doit faire dans l'ordre suivant:
journal avant de modifier la BD (valeur de X) 1) crire sur disque les enregistrements LOG
sur le disque. indiquant les lments BD changs
U 2) Ncrire le COMMIT dans le journal que aprs 2) crire sur disque les lments BD changs eux-

lcriture sur le disque de toutes les mises jour mmes

de la transaction 3) crire l'enregistrement COMMIT du LOG sur le
disque

Cet ordre sapplique individuellement pour

chaque mise jour
21 22

Exemple de journalisation undo Procdure de reprise (undo)

Action de T v M.A M.B D.A D.B Journal
1 < Start T >
Objectif: restaurer l'atomicit
2 Read (A,v) 8 8 8 8
3 v := v*2 16 8 8 8 Examiner le fichier log (en remontant du plus rcent au
4 Write (A,v) 16 16 8 8 < T, A, 8 > moins rcent):
5 Read (B,v) 8 16 8 8 8
Pour les transactions pour lesquelles existe un COMMIT sur
6 v := v*2 16 16 8 8 8 disque
7 Write (B,v) 16 16 16 8 8 < T, B, 8 > ne rien faire
8 Flush Log On crit le LOG avant d'crire les MAJ sur disque Pour les autres transactions (on a <START T> mais pas de
9 Output (A) 16 16 16 16 8 <COMMIT T>), pour chaque entre < T, X, v>:
10 Output (B) 16 16 16 16 16 dfaire chaque mise jour: rcrire l'ancienne valeur
11 < Commit T >
faire WRITE (X,v); OUTPUT(X);
12 Flush Log crire un <Abort T> dans le fichier log
On met l'enregistrement Commit aprs MAJ donnes sur disque Flush Log
23 24

Cours Ingnierie des bases de donnes 4

LBD - C. Vangenot 21 avril 2005

Procdure de reprise - EXEMPLE En rsum:

Action de T Journal
1 < Start T > si panne aprs 12: pas de pb

<Start T> <Start T>
2 Read (A,v) si panne 11 et <Commit T>
non crit dans le LOG, ou < T, A, 8 > < T, A, 8 >
3 v := v*2 entre 8 et 11:
4 Write (A,v) < T, A, 8 > dfaire T: < T, B, 8 > < T, B, 8 >
5 Read (B,v) Write(B, 8); output(B)
Write(A, 8); output(A) <Commit T>
6 v := v*2 Ajouter <ABORT T> dans LOG
7 Write (B,v) < T, B, 8 > FlushLog Write(B,8); Output(B)
8 Flush Log si panne avant 8, OK Write(A,8); Output(A)
9 Output (A) <T, B, 8> et <T,A,8> non

crits dans le LOG mais pas de Si nouvelle panne pendant reprise, ajouter <Abort T> dans LOG
10 Output (B) problmes car les donnes pas de pb car on rcrit l'ancienne
n'ont pas t crites sur disque. Flush Log
11 < Commit T > valeur, on peut recommencer une
12 Flush Log 25
procdure de Reprise 26

Checkpoint Checkpoint
A priori en cas de reprise, on devrait remonter tout le
fichier log. Checkpoint:
Mais peut tre long! 1) Ne plus accepter de nouvelles transactions
2) Attendre la fin des transactions en cours et qu'elles
Ide: stabiliser le log priodiquement
aient crit un enregistrement Commit ou Abort sur
criture dun CHECKPOINT
le LOG
3) Flush Log
4) Ecrire un enregistrement <CKPT>
5) Flush Log
6) Recommencer accepter de nouvelles transactions

27 28

Reprise avec Checkpoint Exemple

<START T1>
Examiner le fichier log (en remontant) jusqu' <T1, A, 5>
l'enregistrement <CKPT> <START T2>
<T2, B, 10>
On dcide de faire un CKPT
Les transactions avant le CKPT se sont <T2, C, 15>
termines correctement et leurs mises jour <T1, D, 20>
On attend la fin de T1 et T2
<COMMIT T1>
ont t crites sur disque. avant d'crire <CKPT>
<COMMIT T2>

Les transactions aprs le CKPT doivent tre <CKPT> T3 est la seule transaction
dfaites comme prcdemment.
<START T3> incomplte qui doit faire
<T3, E, 25>
l'objet d'une reprise
<T3, F, 30>
------ PANNE
29 30

Cours Ingnierie des bases de donnes 5

LBD - C. Vangenot 21 avril 2005

Nonquiescent Checkpoint Reprise avec Nonquiescent Checkpoint

Objectif : ne pas ralentir le systme en refusant de Reprise :

nouvelles transactions Si on rencontre un <END CKPT> alors on sait que toutes les
Mthode Nonquiescent Checkpoint : transactions incompltes sont situes aprs le dernier dernier
< START CKPT(...)> donc pas la peine de remonter plus en
1) Enregistrer dans le fichier log un enregistrement contenant
la liste des transactions en cours: avant que ce START CKPT.
< START CKPT (T1, T2, ... Tn) > Si on rencontre un < START CKPT(T1, Tn)> alors la panne
2) Flush Log a eu lieu pendant le checkpoint. Les transactions incompltes
sont celles rencontres entre la panne et le < START
3) Attendre la fin des transactions en cours, sans interdire le
dmarrage de nouvelles transactions CKPT(...)> et celles parmi T1, , Tn qui ne sont pas
termines. On doit remonter jusqu'au <START > de la plus
4) Quand les transactions T1, T2, ... Tn ont termin, crire un
enregistrement < END CKPT > vieille de ces transactions.
5) Flush Log
31 32

Exemple (1) Exemple (2)

LOG <T3, F, 30> LOG <T3, E, 25>
T3 doit tre dfaite car on ne trouve pas de Pas de Commit donc T3 s'est mal termine, on doit la
<START T1> <START T1> dfaire (rcrire 25 pour E)
COMMIT -> on rcrit la valeur 30 pour F
<T1, A, 5> <T1, A, 5> <T1, D, 20>
<END CKPT> comme on a rencontr un <COMMIT T1>, T1 s'est bien
<START T2> <START T2>

on sait que toutes les transactions incompltes termine donc on ne fait rien
<T2, B, 10> sont situes aprs le 1er <START CKPT> trouv. <T2, B, 10> <START T3>: T3 a t compltement dfaite
<START CKPT (T1,T2)> <T3, E, 25> <START CKPT (T1,T2)> <T2, C, 15>
<T2, C, 15> on doit rcrire la valeur 25 pour E <T2, C, 15> Pas de Commit donc T2 s'est mal termine, on doit la
dfaire (rcrit C=15)
<START T3> <START T3>
<T1, D, 20> <START CKPT (T1,T2)>
<T1, D, 20> comme on a rencontr un <COMMIT T1>, T1 s'est <T1, D, 20> Les transactions incompltes sont celles rencontres entre
bien termine donc on ne fait rien la panne et le START CKPT(T1,Tn) et celles parmi T1, ,
<COMMIT T1> <COMMIT T1> Tn qui ne sont pas termines: {T1, T2, T3}
<T3, E, 25> <T2, C, 15> <T3, E, 25> Or T1 a t valide, T3 dfaite.
On doit continuer jusqu'au START de T2 (seule transaction
<COMMIT T2> comme on a rencontr un <COMMIT T2>, T2 s'est ------- PANNE qui reste n'ayant pas t entirement dfaite)
bien termine donc on ne fait rien
<END CKPT> <T2, B, 10>:
<T3, F, 30> <START CKPT (T1,T2)> on rcrit B=10
on s'arrte <START T2>:
------- PANNE

33 On s'arrte 34

Rgles de journalisation REDO (1) Rgles de journalisation REDO (2)

Inconvnient de Journalisation UNDO: on ne UNDO: dfait les transactions incompltes et ignore les
peut pas faire un commit d'une transaction sans transactions valides
avoir crit toutes les donnes modifies sur le REDO: ignore les transactions incompltes et refait les
disque (output). transactions valides

Or il peut tre intressant (gain I/O) de laisser

les donnes en mmoire avant d'aller les crire UNDO : crit les mises jour avant dcrire le Commit
sur disque REDO : crit le Commit avant dcrire les mises jour

Journalisation REDO: permet de ne pas crire

UNDO : log des mises jour avec anciennes valeurs
immdiatement les mises jour sur les disques

REDO : log des mises jour avec nouvelles valeurs

35 36

Cours Ingnierie des bases de donnes 6

LBD - C. Vangenot 21 avril 2005

Rgles de journalisation REDO (3) Exemple de journalisation redo

Action de T v M.A M.B D.A D.B Journal
1) < Start T >
Mmes enregistrements que pour UNDO 2) READ (A,v) 8 8 8 8
3) v := v*2 16 8 8 8
Sauf signification de <T, X, v> 4) WRITE (A,v) 16 16 8 8 < T, A, 16 >
Transaction T crit la nouvelle valeur v pour X 5) READ (B,v) 8 16 8 8 8
6) v := v*2 16 16 8 8 8
Rgle d'criture dans le fichier LOG: 7) WRITE (B,v) 16 16 16 8 8 < T, B, 16 >
R1) Avant de modifier un lment de la BD sur le 8) < Commit T >
disque, tous les enregistrements de LOG lis cette 9) Flush Log On crit le LOG avant d'avoir crit les donnes sur disque
modification (<T, X, v> et <COMMIT T>) doivent 10) Output (A) 16 16 16 16 8
11) Output (B) 16 16 16 16 16
tre sauvegards sur le disque
On met l'enregistrement Commit AVANT MAJ donnes sur disque

37 38

Rgle pour redo Exemple reprise pour REDO

Action de T Journal si panne aprs 9: LOG contient
l'enregistrement <Commit T>. On va
Avant de modifier une donne sur le disque, crire le 1) < Start T > donc rcrire les valeurs pour A et B
2) READ (A,v) telles que dans les enregistrements <T,
<T, X, v> et le <Commit T> dans le LOG A, 16 > et < T, B, 16 >
3) v := v*2
si panne entre 10 et 11 On rcrit les
Reprise : 4) WRITE (A,v) < T, A, 16 >

valeurs de A et B, la valeur de A est dj

1) Identifier les transactions qui ont fait Commit crite mais ce n'est pas gnant
5) READ (B,v)
2) Balayer le fichier LOG du dbut. Pour chaque ordre <T,X,v>: si panne avant 8:
6) v := v*2 pas de Commit dans le LOG. T est
Si T n'a pas fait de Commit: ignorer la mise jour (elle na pas t considre comme une transaction
crite sur le disque), 7) WRITE (B,v) < T, B, 16 > incomplte
Si T a fait un Commit: refaire la mise jour (crire la valeur v pour X) 8) < Commit T > Les MAJ de T n'ont pas t crites
sur disque, on ne fait rien
3) Pour chaque transaction incomplte T, crire 9) Flush Log Ajouter <ABORT T> dans LOG
<Abort T>, Flush Log 10) Output (A) si panne entre 8 et 9:
si commit crit (flush par autre
11) Output (B)
transaction par ex), idem aprs 9
39 sinon idem avant 40

Checkpoint Checkpoint et redo

Vu que le commit est crit avant le output, les tapes:

MAJ faites par une transaction peuvent avoir t 1) crire < START CKPT (T1, T2, ..., Tn) > o T1, ,
copies sur disque bien aprs que le COMMIT Tn sont les transactions actives non valides (pas
ait eu lieu Commit)
2) Flush Log
Donc le CKPT ne peut pas regarder que les
3) crire sur le disque (vider les tampons) les mises
transactions actives qui sont valides ou non. jour des transactions valides (commit) avant le
Quiescient ou nonquiescent: durant le CKPT checkpoint
on doit forcer l'criture sur disque des lments 4) crire < END CKPT >
modifis par des transactions valides. 5) Flush Log
41 42

Cours Ingnierie des bases de donnes 7

LBD - C. Vangenot 21 avril 2005

Reprise avec Checkpoint (1) Reprise avec Checkpoint (2)

Si la panne a lieu aprs <END CKPT> Si la panne a lieu aprs un < START CKPT(T1,
On sait que les valeurs crites par transactions valides , Tn)>
(Commit) avant <START CKPT(T1,..,Tn)> sont maintenant
sur disque. On ne sait pas si les valeurs crites par transactions
Les transactions parmi T1, , Tn ou ayant commenc aprs valides (Commit) avant <START CKPT(T1,..,Tn)>
le <START CKPT>, n'ont pas forcment leurs valeurs crites sont sur disque.
sur disque mme si elles ont fait Commit. On doit trouver le dernier enregistrement <END
On doit donc faire la reprise pour REDO de ces transactions:

CKPT>, trouver son <START CKPT(S1,..,Sn)> et
Si T n'a pas fait de Commit: ignorer la mise jour (elle na pas t crite
sur le disque), refaire toutes les transactions valides qui ont soit
Si T a fait un Commit: refaire la mise jour (crire la valeur v pour X) commenc aprs ce <START CKPT(S1,..,Sn)> ou
On ne doit pas regarder plus haut dans le LOG que le plus qui font partie de S1Sn
vieux <START Ti> o Ti est une de T1, , Tn ou ayant
commenc aprs le <START CKPT> 43 44

Reprise avec Checkpoint Reprise avec Checkpoint

On recherche le <END CKPT>
LOG On recherche le <END CKPT> LOG
<START T1> <START T1>
Les transactions qu'on va refaire sont soit celles
Les transactions qu'on va refaire sont soit celles qui ont commenc aprs <START CKPT (T2)> ou
<T1, A, 5> qui ont commenc aprs <START CKPT (T2)> ou <T1, A, 5> {T2}
<START T2> {T2} <START T2> {T2, T3}
<COMMIT T1> {T2, T3} <COMMIT T1> Les valeurs mises jour par T1 sont sur disque
<T2, B, 10> Les valeurs mises jour par T1 sont sur disque <T2, B, 10>
Seule T2 a fait un Commit, ses valeurs doivent
<START CKPT (T2)> T2 et T3 ont fait un Commit, leurs valeurs doivent <START CKPT (T2)> tre rcrites. Les MAJ de T3 sont ignores
<T2, C, 15> tre rcrites <T2, C, 15>
On remonte jusqu' <START T2> (la plus
<START T3> On remonte jusqu' <START T2> (la plus <START T3> ancienne), on trouve les MAJ:
<T3, D, 20> ancienne), on trouve les MAJ: <T3, D, 20> <T2, B, 10>
<END CKPT> <T2, B, 10> <END CKPT> <T2, C, 15>
<T2, C, 15>
<COMMIT T2>
<T3, D, 20>
<COMMIT T2> On rcrit ces 2 valeurs
<COMMIT T3> ------- PANNE On crit un <ABORT T3>
On rcrit ces 3 valeurs

------- PANNE <COMMIT T3>

45 46

Reprise avec Checkpoint UNDO/REDO

<START T1> On recherche le premier <START
<T1, A, 5>

Inconvnients de UNDO et de REDO:
CKPT()> avant <START CKPT(T2)>
<START T2> UNDO ncessite que les donnes soient crites sur
Or il n'existe pas donc on remonte au
<COMMIT T1>
disque avant que le Commit soit crit dans le journal
<T2, B, 10> dbut du LOG
ce qui entrane bcp de I/O
<START CKPT (T2)>
La seule transaction valide est T1.
REDO au contraire demande ce que les donnes

<T2, C, 15>
<START T3> On refait sa mise jour. restent dans les buffers tant que la transaction n'est
on rcrit la valeur 5 pour A
<T3, D, 20>
pas valide et que le fichier LOG est crit. Le
------- PANNE
On crit un <ABORT T2> et<ABORT nombre de buffers ncessaires est donc augment.
<END CKPT>
T3>
<COMMIT T2>
<COMMIT T3>
-> Journalisation UNDO/REDO

47 48

Cours Ingnierie des bases de donnes 8

LBD - C. Vangenot 21 avril 2005

UNDO/REDO Exemple de journalisation UNDO/REDO

Action de T v M.A M.B D.A D.B Journal

Mmes enregistrements que pour UNDO et REDO 1) < Start T >

2) READ (A,v) 8 8 8 8

sauf UPDATE: <T, X, v,w> 3) v := v*2 16 8 8 8

Transaction T a chang la valeur de X, l'ancienne valeur tait 4) WRITE (A,v) 16 16 8 8 < T, A, 8, 16 >
v, la nouvelle valeur w 5) READ (B,v) 8 16 8 8 8
6) v := v*2 16 16 8 8 8
Rgle d'criture dans le fichier LOG 7) WRITE (B,v) 16 16 16 8 8 < T, B, 8, 16 >
UR1) Avant de modifier un lment X de la BD sur le disque, il 8) Flush Log
< Commit T >
est ncessaire qu'un enregistrement de mise jour <T, X, < Commit T >
9) Output (A) 16 16 16 16 8
v,w> soit crit sur le disque.
10) < Commit T >

<COMMIT T> peut tre avant ou aprs l'criture sur disque de X 11) Output (B) 16 16 16 16 16
< Commit T >

49 50

Reprise avec UNDO/REDO Exemple de panne avec UNDO/REDO

Action de T Journal
On a les informations soit pour dfaire soit pour 1) < Start T >
Panne aprs 10 (mais
refaire une maj 2) READ (A,v) journal comprend
3) v := v*2 commit), T est valide.
Reprise: 4) WRITE (A,v) < T, A, 8, 16 >
On refait toutes ses MAJ:
5) READ (B,v)
Refaire toutes les transactions valides (en 6) v := v*2
on rcrit la nouvelle
descendant le log) 7) WRITE (B,v) < T, B, 8, 16 > valeur de A (inutile) et B
8) Flush Log
Dfaire les transactions non-valides (en remontant Panne avant 10: T n'est
le log) pas valide. Ses MAJ
9) Output (A)
10) < Commit T > sont dfaites:on rcrit
11) Output (B) l'ancienne valeur de A et
B
51 52

Checkpoint avec UNDO/REDO Reprise avec Checkpoint

LOG T2 est la seule transaction active au
tapes: 1) <START T1>

moment du Checkpoint.
1) crire < START CKPT (T1, T2, ..., Tn) > o T1, , 2) <T1, A, 4, 5> Durant le Checkpoint, on crit sur
Tn sont les transactions actives (pas Commit) 3) <START T2> disque les valeurs de A et B
4) <COMMIT T1>
2) Flush Log Si une panne arrive en 13:
5) <T2, B, 9, 10>
Pour T1 on ne fait rien, elle est valide et
3) crire sur le disque (vider les tampons) les mises 6) <START CKPT (T2)> ses valeurs ont t crite sur disque
durant le CKPT
jour de toutes les transactions actives (valides ou 7) <T2, C, 14, 15>
T2 et T3 ont t valides (Commit), on
8) <START T3> refait leurs mises jour depuis le <START
non) ou termines avant le checkpoint 9) <T3, D, 19, 20> CKPT (T2)> car les mises jour avant le
CKPT ont dj crites sur disque (<T2, B,
4) crire < END CKPT > 10) <END CKPT> 9, 10>)
11) <COMMIT T2>
5) Flush Log Si une panne arrive entre 11 et 12:
12) <COMMIT T3>
On refait T2, on dfait T3
13)
53 54

Cours Ingnierie des bases de donnes 9

LBD - C. Vangenot 21 avril 2005

Comment reconstruire la BD aprs

destruction du disque? Archivage

Comment reconstruire la base de donnes aprs la Solution:

destruction des disques contenant les donnes? Archiver la base de donnes date t
Reconstruire la BD en utilisant cette archive et
Log: ventuellement le LOG depuis le moment de l'archivage pour
restaurer les mises jour aprs panne quand donnes en avoir un tat plus avanc (t+x)
mmoire sont perdues mais les donnes sur disque ne sont Diffrents niveaux d'archivage:
pas perdues.
"Full dump"
Utilisation du LOG pour reconstruire la BD? "Incremental dump"
Il faudrait conserver tout le LOG Mixte:
niveau 0: "full dump"
LOG conserv sur un autre disque que les donnes niveau 1: "incremental dump" depuis niveau 0
LOG UNDO/REDO ou REDO (pour avoir les nouvelles valeurs) niveau 2: "incremental dump" depuis niveau 1
Pas raliste car LOG devient vite trs volumineux

55 56

Non-quiescient archive Exemple

On ne peut pas arrter la BD pour faire BD avec 4 lments A, B, C, D

archivage tat de la BD au dbut de l'archivage:
A=1, B=2, C=3, D=4
-> non-quiescient archive
tat de la BD la fin de l'archivage !
Cependant: A=5, B=7, C=6, D=4
La copie de la BD est faite alors que des mises tat de l'archive ! Disque Archive
jour peuvent encore tre faites sur la BD A=1, B=2, C=6, D=4 Copy A
Pour restaurer on a besoin de l'archive et du log des A:=5
Squence d'vnements Copy B
transactions actives pendant l'archivage arrivant sur la BD: C:=6
LOG UNDO/REDO ou REDO Copy C
B:=7
57 58 Copy D

Non-quiescient archive Exemple de fichier Log avec UNDO/REDO

LOG
Mthode de cration d'une archive:
<START DUMP>
1) crire un enregistrement <START DUMP> sur le
<START CKPT (T1, T2)>
LOG
<T1, A, 1, 5>
2) Faire un checkpoint adapt la mthode de
journalisation utilise (UNDO/REDO ou REDO) <T2, C, 3, 6>
<COMMIT T2>
3) Faire une copie (full dump ou incremental dump)
<T1, B, 2, 7>
4) S'assurer que le fichier log partir au moins du
<COMMIT T1>
checkpoint (inclus) est sauvegard sur un disque sr
<END CKPT>
5) crire un enregistrement <END DUMP> sur le LOG
----Fin de l'archivage
<END DUMP>
59 60

Cours Ingnierie des bases de donnes 10

LBD - C. Vangenot 21 avril 2005

Reprise avec archive et log Exemple

tapes: Exemple de BD avec A, B, C, D

Reconstruire la BD partir de l'archive la plus 1) on restaure avec les valeurs de l'archive:
rcente A=1, B=2, C=6, D=4
Modifier la BD l'aide du LOG (utiliser la mthode 2) on regarde le fichier LOG
de reprise correspondant au type de journalisation Comme T1 et T2 ont t valides (Commit), on refait leurs
utilise (UNDO/REDO ou REDO)) MAJ:
<T1, A, 1, 5>, A :=5
<T2, C, 3, 6>, C:=6
<T1, B, 2, 7>, B:=7

La BD restaure a les valeurs suivantes:

A=5, B=7, C=6, D=4 OK!

61 62

Cours Ingnierie des bases de donnes 11