Reprise

1
Reprise

• Chapitre 18

2
Objectifs

• Vol et forçage rappel
• Le log
• organisation
• maintient et utilisation
• Autres structures de données
• Protocole WAL
• Points de contrôle
• Reprise
• après un plantage
• après une faillite de disque

3
Rappel Les Propriétés ACID

• Atomicité Soit que toutes les actions dune
  transaction sont exécutées soit aucune nest
  exécutée.
• Consistance Toute transaction qui commence son
  exécution dans un état consistant de la base de
  données doit laisser la base de données dans un
  état consistant.
• Isolation Une transaction est protégée des
  effets des autres transactions exécutant
  simultanément.
• Durabilité Les effets des transactions validées
  doivent persister et survivre toute défaillance
  du systèm.
• Le gestionnaire de la reprise garantit
  latomicité et la durabilité.

4
Motivation et Example

• Assomptions
• Contrôle de laccès simultané en place Strict
  2PL.
• Les changements surviennent sur place dans le
  disque par voie décrasement
• Le gestionnaire des reprises garantit
• Atomicité Les transactions peuvent être
  abandonnées .
• Durabilité Comment garantir la durabilité
  lorsque le SGBD se plante ou en cas de faillite
  du disque?

• Comportement désirable après la reprise du
  système
• T1, T2 T3 devraient être durables.
• T4 T5 devraient être abandonnés (leurs effets
  devraient être invisibles).

plantage!
T1 T2 T3 T4 T5
5
Vol et Forçage Rappel

• Forcer chaque écriture vers le disque?
• Temps de réponse inefficient.
• Garantit la durabilité.
• Voler des cadres de la mémoire tampon auprès des
  transaction non encore validées?
• Si oui, il est difficile dassurer latomicité?
• Si non, le débit du système sera bas.

Non vol
vol
Trivial inefficient
Forçage
Non Forçage
Désiré
6
Vol et Non Forçage Détails

• VOL (difficultés pour garantir latomicité)
• Pour voler un cadre F, la page courante P (qui
  est verrouillée par une transaction T) logée dans
  F est écrite sur disque. Quest ce qui arrive si
  T est abandonnée?
• Lon ne pourra défaire T proprement que si lon
  peut se rappeler de la vieille valeur de P au
  moment du vol (Ceci aidera à supporter
  lopération UNDO pour défaire les écritures
  faites sur P).
• NON FORCAGE (difficultés pour garantir la
  durabilité)
• Que faire si le système se plante avant que une
  page modifiée ne soit écrite sur disque?
• Ecrire aussi peu que possible les traces des
  changements en un endroit sûr au moment de la
  validation, afin de supporter une éventuelle
  opération REDO pour refaire tous les changement
  effectués avant la validation.

7
Idée de Base Journalisation (Logging)

• Enregistrer toute information sur les changements
  effectués sur la base de données dans un journal
  (log) afin de faciliter les opérations
  subséquentes de REDO et UNDO.
• Les écritures dans le journal se font de manière
  séquentielle (et stockées sur un disque séparé).
• Rien que de linformation minimale est mise dans
  le log afin de sauvegarder de lespace disque.
• Le log est une liste ordonnée des actions
  exécutées par le SGBD.
• un fichier denregistrements (on en verra la
  forme plus loin)
• stocké sur support stable (disque)
• deux ou plusieurs copies maintenues sur
  différents disques, voire en des lieux différents

8
Journalisation WAL

• Le protocole Write-Ahead Logging (WAL)
• Doit forcer lenregistrement au sujet dun
  changement du log vers le disque avant que la
  page de données correspondante ne soit écrite sur
  disque.
• Doit écrire tous les enregistrements du log pour
  une transaction T avant que T ne valide son
  travail.
• 1 garantit latomicité.
• 2 garantit durabilité.
• Exemple concret de journalisation et reprise
• Lalgorithme ARIES

9
Journal WAL

• Chaque enregistrement du log a une identité
  unique Log Sequence Number (LSN).
• Les LSNs forment une série croissante.
• Chaque page de données contient un pageLSN.
• pageLSN est le LSN du plus récent enregistrement
  du log correspondant à un changement sur ladite
  page.
• Le SGBD maintien un LSN appelé flushedLSN.
• Cest le maximum des LSNs stockés sur disque
  jusquà date.
• WAL Avant que une page soit écrite,
• pageLSN flushedLSN

Enreg. du log stockés sur disque
Log tail dans le RAM
10
Enregistrements du Log

• Types denregistrements
• Update
• Commit
• Abort
• End (signifie la fin de Commit ou Abort)
• Enregistrements compensatoires (Compensation Log
  Records -
• CLRs)
• Pour les actions UNDO

Champs du LogRecord
Info pour Les types update seulement
11
Structures Additionnelles pour la Reprise

• Table des transactions (Transaction Table)
  contient une entrée par transaction active avec
  au moins linfo suivante
• transID
• status (running/commited/aborted)
• lastLSN (le LSN de la plus récente entrée du log
  pour la transaction)
• Table des pages modifiées (Dirty Page Table)
  Contient une entrée par page modifiée dans le
  pool tampon avec au moins linfo suivante
• pageID (identité de la page modifiée)
• recLSN (le LSN de lenregistrement du log qui a
  engendré le premier changement sur la page)

12
Exécution Normale dune Transaction

• Série de reads writes, suivis par un Commit ou
  Abort.
• Nous supposons que les écritures sur le disque
  sont atomiques.
• En pratique, il y a des détails dont il faut
  tenir compte afin de traiter des écritures
  non-atomiques.
• Le protocole Strict 2PL est utilisé pour le
  contrôle de laccès simultané.
• Lapproche VOL/NON-FORCAGE est utilisée pour la
  gestion du pool tampon, en combinaison avec le
  protocole WAL.

13
Points de Reprise

• Un SGBD crée périodiquement un point de reprise
  (checkpoint) afin de minimaliser le temps de
  reprise en cas de plantage. Ces points de reprise
  sont générés par les entrées suivantes dans le
  log
• begin_checkpoint Début du point de reprise.
• end_checkpoint Contient les tables courantes
  des transactions et des pages modifiées (fuzzy
  checkpoint)
• Dautres transactions continuent à exécuter lors
  de la construction du end_checkpoint ainsi donc
  ces tables ne sont vraiment précises quau moment
  du begin_checkpoint.
• Ces points de reprise sont limités par le
  recLSN, doù une écriture périodique des pages
  modifiées sur disque est souhaitable.
• Stocker le LSN du point de reprise en un endroit
  sûr (master record).

14
Survol des Lieux de Stockage des Structures
LOG
RAM
DB
LogRecords
Table des transactions lastLSN status Table
des pages modifiées recLSN flushedLSN
Pages de données chacune avec un pageLSN
master record
15
Abandon dune Transaction par un Utilisateur

• UNDO défaire les changements dune transaction
  T.
• Ecrire un enregistrement de type Abort dans le
  log. (Utile pour des reprises dun plantage lors
  de lexécution de UNDO)
• Obtenir la valeur lastLSN de T de la table des
  transactions.
• Parcourir le log à reculons en suivant la chaine
  des enregistrement de T via les valeurs de
  prevLSN.
• Avant de restaurer la vieille valeur dune page,
  écrire un CLR
• On continue à journaliser pendant lexécution de
  UNDO!!
• Le CLR a un champ supplémentaire undonextLSN
• Ce champ est un pointeur vers le prochain LSN à
  défaire (i.e. le prevLSN de lenregistrement qui
  est entrain dêtre abandonné).
• Les CLRs ne sont jamais défaites (Elles sont
  refaites en cas de répétition de lhistorique
  pour garantir latomicité).
• Ecrire un enregistrement de type End dans le log.

16
Validation dune Transaction (Commit)

• Validation dune Transaction T
• Ecrire un enregistrement de type Commit dans le
  log.
• Tous les enregistrements du log jusquau lastLSN
  de T sont envoyés séquentiellement et de manière
  synchronisée vers le disque.
• Ceci garantit que flushedLSN ³ lastLSN.
• En général, il y a plusieurs enregistrements par
  page du log.
• Ecrire un enregistrement de type End dans le log.

17
Reprise Aperçu General

• Commencer par trouver le plus récent checkpoint
  (en consultant le master record).
• Ensuite parcourir trois phases
• Analyse Trouver
• quelles transactions ont été validées depuis ce
  dernier checkpoint,
• lesquelles nont pas terminé,
• autres infos utiles.
• REDO refaire toutes les actions des
  transactions déjà validées .
• (i.e. répéter lhistorique)
• UNDO défaire les effets des transactions non
  terminées.

Plus ancien enreg. du log pour les transactions
actives lors du crash
Plus petit recLSN dans la table des pages
modifiées à la fin de lanalyse
Dernier chkpt
CRASH
A
R
U
18
Reprise Phase de lAnalyse

• Reconstruire létat de la base de données au
  dernier checkpoint (Utiliser les enregistrements
  du type end_checkpoint).
• Scanner le log vers lavant à partir du
  checkpoint. Selon le type des enregistrements
  rencontrés, faire ce qui suit
• End enlever la transaction correspondante de la
  table des transactions.
• Enregistrement autre que End ajouter la
  transaction correspondante T à la table des
  transactions (si T ny est pas encore)
• lastLSN de T est maintenant égal au LSN de
  lenregistrement
• Si lenregistrement est Commit, changer le
  statut de T à C, sinon changer le statut à U
  (i.e. à défaire).
• Update Si la page P affectée nest pas déjà
  dans la table des pages modifiées
• ajouter P à la table des pages modifiées
• recLSN de T est maintenant égal au LSN de
  lenregistrement

19
Reprise Phase REDO

• Nous répétons lhistorique (le log) afin de
  reconstruire létat au moment de la panne
• Refaire tous les changements, ainsi que les CLRs.
• Scanner le log vers lavant à partir de
  lenregistrement du log avec le plus petit recLSN
  dans la table des pages modifiées. Chaque action
  dun CLR ou dun changement LSN est refait, sauf
  si
• La page affectée nest pas dans la table des
  pages modifiées, ou
• La page affectée est dans la table des pages
  modifiées, mais recLSN gt LSN, ou
• pageLSN ³ LSN.
• Pour refaire une action
• Réappliquer laction du log.
• Changer pageLSN à LSN. Aucune journalisation
  nest faite.

20
Reprise Phase UNDO

• ToUndo l l lastLSN des transactions
  perdantes
• Répéter
• Choisir le plus grand LSN de lensemble ToUndo.
• Si ce LSN est un CLR et undonextLSNNULL
• Ecrire un enregistrement End dans le log pour
  cette transaction.
• Si ce LSN est un CLR et undonextLSN ! NULL
• Ajouter undonextLSN à lensemble ToUndo
• Sinon ce LSN est un changement. Défaire le
  changement, écrire un CLR, ajouter prevLSN à
  lensemble ToUndo.
• Jusquà ce que ToUndo est vide.

21
Exemple de Reprise
LSN LOG
begin_checkpoint end_checkpoint update T1
writes P5 update T2 writes P3 T1 abort CLR Undo
T1 LSN 10 T1 End update T3 writes P1 update T2
writes P5 CRASH, RESTART
00 05 10 20 30 40
45 50 60
prevLSNs
Table des transactions lastLSN status Table des
pages modifiées recLSN flushedLSN
ToUndo
22
Exemple Panne Durant la Phase UNDO
LSN LOG
begin_checkpoint, end_checkpoint update T1
writes P5 update T2 writes P3 T1 abort CLR Undo
T1 LSN 10, T1 End update T3 writes P1 update T2
writes P5 CRASH, RESTART CLR Undo T2 LSN 60 CLR
Undo T3 LSN 50, T3 end CRASH, RESTART CLR Undo
T2 LSN 20, T2 end
00,05 10 20 30 40,45 50
60 70 80,85 90
undonextLSN
Table des transactions lastLSN status Table des
pages modifiées recLSN flushedLSN
ToUndo
23
Autres Cas de Pannes

• Que se passe-t-il si le système tombe en panne
  durant la phase de lanalyse ou la phase REDO?
• Comment limiter la quantité de travail durant la
  phase REDO?
• Stocker périodiquement et de manière
  asynchronique à larrière plan.
• Comment limiter la quantité de travail durant la
  phase UNDO?
• Eviter les transactions très longues.

24
Résumé de la Journalisation/Reprise

• Le gestionnaire de la reprise garantit
  latomicité et la durabilité.
• Utilisation du protocole WAL pour implémenter
  lapproche VOL/NON FORCAGE.
• Les LSNs identifient les enregistrements du log
  lenchainement des LSNs appartenant à la même
  transaction est fait par les prevLSNs.
• Les pageLSNs permettent de comparer les pages des
  données et les enregistrements du log.
• Point de reprise mécanisme pour limiter la
  longueur de la portion du log à scanner.
• Reprise en 3 phases Analyse, REDO et UNDO

25
Résumé (Suite)

• Point de reprise mécanisme pour limiter la
  longueur de la portion du log à scanner.
• Reprise en 3 phases Analyse, REDO et UNDO