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? plantage! v 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). 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. Forçage Non Forçage Non vol vol Trivial & inefficient 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 pageLSN 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 prevLSN transID type length pageID offset before-image after-image 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 DB Pages de données: chacune avec un pageLSN Table des transactions lastLSN status Table des pages modifiées recLSN flushedLSN RAM prevLSN transID type length pageID offset before-image after-image LogRecords LOG 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 v Commencer par trouver le plus récent checkpoint (en consultant lemaster record). v 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. u (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 RU

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 > 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 undonextLSN==NULL 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 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 LSN LOG Table des transactions lastLSN status Table des pages modifiées recLSN flushedLSN ToUndo prevLSNs RAM

22 Exemple: Panne Durant la Phase UNDO 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 LSN LOG 00, , ,85 90 ToUndo undonextLSN RAM Table des transactions lastLSN status Table des pages modifiées recLSN flushedLSN

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