144
Introduction pratique aux bases de données relationnelles
Technique
d’annulation des
transactions
Le mécanisme de l'annulation des transactions est illustré par la
figure 4-14 : après une panne, le système parcourt le journal depuis la
fin jusqu'au point de reprise le plus récent. Les transactions qui
retiennent l'attention sont celles qui ne portent pas encore la marque
EOT (EOT = End Of Transaction) signalant leur achèvement normal. Il
s'agit des deux transactions TRX_2 et TRX_5 qu'il faut maintenant
défaire (undo, en anglais) à l'aide du journal afin de rétablir l'ancien
état de la base de données. À cette fin, le système part du point de
reprise et remonte jusqu'à la marque BOT (BOT = Begin Of
Transaction) de la transaction TRX_5 pour retrouver l'image avant de
TRX_5. Indépendamment de la nature du point de reprise, le système
doit aussi regénérer (redo, en anglais) l'état le plus récent (after image,
en anglais) produit au moins par la transaction TRX_4.
Figure 4-14
Reprise d’un
système de bases
de données après
une panne
Organisation de la
sauvegarde
Après une panne, pour reconstruire une base de données sur des
unités de mémoire externe, nous devons disposer d'une copie
d’archive de la base de données et de l'ensemble des modifications
exécutées depuis la date de sauvegarde. Les copies d'archive sont
normalement effectuées avant et après les travaux de traitement
exécutés en fin de journée, car l'opération est très gourmande en
temps. Durant la journée, c'est l’enregistrement des modifications
Point de reprise
BOT : Begin of Transaction
EOT : End of Transaction
TRX_1
BOT
EOT
TRX_2
BOT
TRX_3
BOT
EOT
TRX_4
BOT
EOT
TRX_5
BOT
TRX_6
BOT
EOT
Temps
Panne du
système