Exercices du 13 avril 2005
Exercices IBD 1 / 4
Séance d'Exercices IBD N°4
Exercice 1: Fiabilité a)
Si le checkpoint est « quiescient » cela signifie qu’au moment où on a décidé de faire le checkpoint on a attendu que les transactions actives soit valident ou soit annulent leurs mises à jour. Puis, les buffers ont été vidés sur disque. Ensuite l’enregistrement <Checkpoint> a été écrit sur le LOG. On sait donc que toutes les transactions avant le checkpoint ont leurs mises à jour écrites sur disque. La transaction T1 a donc été validée et ses données ont été écrites sur disque.
Les autres transactions T2, T3 et T4 ont débuté après le checkpoint, leurs mises à jour ne sont donc pas forcément sur le disque. Il faut donc appliquer les règles de reprise pour la journalisation UNDO/REDO : On doit refaire les transactions validées (i.e. qui ont fait un Commit) et défaire les autres :
- Les transactions T2 et T3 sont défaites parce qu'elles n'ont pas fait commit avant la panne du système.
- T4 a fait un commit avant la panne du système, elle doit donc être refaite.
b)
Si après le début de la transaction T2, on décide de faire un checkpoint « non-quiescent », le contenu du journal est le suivant (les lectures ont été aussi supprimées pour simplifier le journal):
(start transaction, T1) (W, T1, D, 20, 21) (commit,T1)
(start transaction, T2) (Start checkpoint (T2) ) (W, T2, B, 15, 12)
(start transaction, T4) (W, T4, E, 12, 15) (start transaction, T3) (W, T3, A, 30, 35) (W, T4, F, 35, 20) (commit,T4)
(W, T2, D, 21, 25)
****panne****
Pour la reprise on doit remonter jusqu’au dernier ordre <End checkpoint> ou s’il n’y en a pas, on doit remonter au début du LOG. Ici on doit donc remonter au début du LOG.
De plus, comme le checkpoint est non « quiescient » et que le log ne comprend pas d’ordre <End checkpoint>, on ne peut être sûr que toutes les données modifiées avant le début du checkpoint ont été écrites sur disque. On doit donc appliquer les règles de reprise pour la journalisation UNDO/REDO : On doit refaire les transactions validées (i.e. qui ont fait un Commit) et défaire les autres depuis le début du LOG :
- Ainsi, la transaction T1 est confirmée parce qu'elle a fait commit avant le dernier checkpoint mais on ne sait pas si ses valeurs ont été écrites sur disque car la panne a eu lieu avant la fin du checkpoint. Elle doit donc être refaite.
- Les transactions T2 et T3 sont défaites parce qu'elles n'ont pas fait commit avant la panne du système.
- T4 a fait un commit avant la panne du système, elle doit donc être refaite.
c)
Il n’est pas nécessaire de garder les anciennes valeurs des attributs modifiés (les lectures ont été aussi supprimées pour simplifier le journal).
(start_transaction, T1) (W, T1, D, 21)
(commit, T1) (checkpoint)
(start_transaction, T2) (W, T2, B, 12)
(start_transaction, T4) (W, T4, E, 15)
(start_transaction, T3) (W, T3, A, 35)
(W, T4, F, 20) (commit, T4)
Exercices du 13 avril 2005
Exercices IBD 2 / 4 (W, T2, D, 25)
**** panne du système ****
Si le checkpoint est « quiescient » cela signifie qu’au moment où on a décidé de faire le checkpoint on a attendu que les transactions actives soit valident ou soit annulent leurs mises à jour. Puis, les buffers ont été vidés sur disque. Ensuite l’enregistrement <Checkpoint> a été écrit sur le LOG. On sait donc que toutes les transactions avant le checkpoint ont leurs mises à jour écrites sur disque. La transaction T1 a donc été validée et ses données ont été écrites sur disque.
Les autres transactions T2, T3 et T4 ont débuté après le checkpoint, leurs mises à jour ne sont donc pas forcément sur le disque. Il faut donc appliquer les règles de reprise pour la journalisation REDO : On doit refaire les transactions validées (i.e.
qui ont fait un Commit) et ignorer les autres :
- Les transactions T2 et T3 sont ignorées parce qu'elles n'ont pas fait commit avant la panne du système. On écrit dans le journal un ordre Abort T2 et un ordre Abort T3.
- T4 a fait un commit avant la panne du système, elle doit donc être refaite.
d)
Protocole REDO, panne après le <End Checkpoint>
(start transaction, T1) (W, T1, D, 21)
(commit,T1)
(start transaction, T4) (W, T4, E, 15)
(start checkpoint(T4)) (W, T4, F, 20)
(commit,T4)
(start transaction, T2) (W, T2, B, 12)
(start transaction, T3) (W, T3, A, 35)
(W, T2, D, 25) (end checkpoint) ****panne****
Si la panne a lieu après le <end checkpoint>, on sait que les données modifiées par les transactions ayant fait commit avant le début du checkpoint sont écrites sur disque. La transaction T1 est confirmée et ses données écrites sur disque donc on ne fait rien pour T1.
Pour les transactions en cours ou ayant commencé après le <start checkpoint>, on ne sait pas si les données qu’elles ont modifiées sont déjà sur disque. On doit donc refaire celles qui sont validées (i.e. qui ont fait un Commit) et on ignore les autres. T2, T3 et T4 sont les transactions en cours durant le checkpoint.
- T2 et T3 n’ont pas fait commit donc on ignore leurs mises à jour. On écrit Abort T2 et Abort T3 dans le LOG.
- T4 a fait un commit. On doit donc refaire ses mises à jour.
Protocole REDO, panne avant le <End Checkpoint>
(start transaction, T1) (W, T1, D, 21)
(commit,T1)
(start transaction, T4) (W, T4, E, 15)
(start checkpoint(T4)) (W, T4, F, 20)
(commit,T4)
(start transaction, T2) (W, T2, B, 12)
(start transaction, T3) (W, T3, A, 35)
(W, T2, D, 25)
Exercices du 13 avril 2005
Exercices IBD 3 / 4
****panne****
(end checkpoint)
Si la panne a lieu avant le <end checkpoint>, on doit remonter jusqu’au dernier <end checkpoint> ou s’il n’y en a pas jusqu’au début du LOG. De plus on ne sait pas si les données modifiées par les transactions ayant fait commit avant le début du checkpoint sont écrites sur disque. On doit refaire toutes les transactions validées et ignorer les autres :
- La transaction T1 est confirmée, on doit donc la refaire.
- T2 et T3 n’ont pas fait commit donc on ignore leurs mises à jour. On écrit Abort T2 et Abort T3 dans le LOG.
- T4 a fait un commit. On doit donc refaire ses mises à jour.
Protocole UNDO/REDO, panne après le <End Checkpoint>
(start transaction, T1) (W, T1, D, 20,21)
(commit,T1)
(start transaction, T4) (W, T4, E, 12, 15) (start checkpoint(T4)) (W, T4, F, 35, 20) (commit,T4)
(start transaction, T2) (W, T2, B, 15, 12) (start transaction, T3) (W, T3, A, 30, 35) (W, T2, D, 21, 25) (end checkpoint) ****panne****
Si la panne a lieu après le <end checkpoint>, on sait que les données modifiées par les transactions ayant fait commit avant le début du checkpoint sont écrites sur disque. La transaction T1 est confirmée et ses données écrites sur disque donc on ne fait rien pour T1.
Pour les transactions en cours ou ayant commencé après le <start checkpoint>, on ne sait pas si les données qu’elles ont modifiées sont déjà sur disque. On doit donc refaire celles qui sont validées (i.e. qui ont fait un Commit) et défaire les autres :
- T2, T3 et T4 sont les transactions en cours durant le checkpoint.
- T2 et T3 n’ont pas fait commit donc on défait leurs mises à jour. On écrit Abort T2 et Abort T3 dans le LOG.
- T4 a fait un commit. On doit donc refaire ses mises à jour.
Protocole UNDO/REDO, panne avant le <End Checkpoint>
(start transaction, T1) (W, T1, D, 20,21)
(commit,T1)
(start transaction, T4) (W, T4, E, 12, 15) (start checkpoint(T4)) (W, T4, F, 35, 20) (commit,T4)
(start transaction, T2) (W, T2, B, 15, 12) (start transaction, T3) (W, T3, A, 30, 35) (W, T2, D, 21, 25)
****panne****
(end checkpoint)
Exercices du 13 avril 2005
Exercices IBD 4 / 4
Si la panne a lieu avant le <end checkpoint>, on ne sait pas si les données modifiées par les transactions ayant fait commit avant le début du checkpoint sont écrites sur disque. On doit remonter jusqu’au dernier <end checkpoint> ou s’il n’y en a pas jusqu’au début du LOG. On doit refaire toutes les transactions validées et défaire les autres :
- La transaction T1 est confirmée, on doit donc la refaire.
- T2 et T3 n’ont pas fait commit donc on défait leurs mises à jour. On écrit Abort T2 et Abort T3 dans le LOG.
- T4 a fait un commit. On doit donc refaire ses mises à jour.
