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 d’une transaction sont exécutées soit aucune n’est 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 l’atomicité et la durabilité.

4. Motivation et Example • Assomptions • Contrôle de l’accè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 d’assurer l’atomicité? • 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 l’atomicité) • 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. Qu’est ce qui arrive si T est abandonnée? • L’on ne pourra défaire T proprement que si l’on peut se rappeler de la vieille valeur de P au moment du vol (Ceci aidera à supporter l’opé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 l’information minimale est mise dans le log afin de sauvegarder de l’espace disque. • Le log est une liste ordonnée des actions exécutées par le SGBD. • un fichier d’enregistrements (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 l’enregistrement au sujet d’un 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 l’atomicité. • #2 garantit durabilité. • Exemple concret de journalisation et reprise: • L’algorithme ARIES

9. pageLSN 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éescontient 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. • C’est 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. prevLSN transID type pageID length offset before-image after-image Enregistrements du Log Champs du LogRecord: Types d’enregistrements: • Update • Commit • Abort • End (signifie la fin de Commit ou Abort) • Enregistrements compensatoires (Compensation Log Records - CLRs) • Pour les actions UNDO 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 l’info 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 l’info suivante: • pageID (identité de la page modifiée) • recLSN (le LSN de l’enregistrement du log qui a engendré le premier changement sur la page)

12. Exécution Normale d’une 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 l’accès simultané. • L’approche 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 transactionset des pages modifiées (`fuzzy checkpoint’): • D’autres transactions continuent à exécuter lors de la construction du end_checkpoint; ainsi donc ces tables ne sont vraiment précises qu’au moment du begin_checkpoint. • Ces points de reprise sont limités par le recLSN, d’où 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. prevLSN transID type pageID length offset before-image after-image 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 d’une Transaction par un Utilisateur • UNDO: défaire les changements d’une transaction T. • Ecrire un enregistrement de type Abort dans le log. (Utile pour des reprises d’un plantage lors de l’exé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 d’une page, écrire un CLR: • On continue à journaliser pendant l’exé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 l’enregistrement qui est entrain d’être abandonné). • Les CLRs ne sont jamais défaites (Elles sont refaites en cas de répétition de l’historique pour garantir l’atomicité). • Ecrire un enregistrement de type End dans le log.

16. Validation d’une Transaction (Commit) • Validation d’une Transaction T: • Ecrire un enregistrement de type Commit dans le log. • Tous les enregistrements du log jusqu’au 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 n’ont pas terminé, • autres infos utiles. • REDO: refaire toutes les actions des transactions déjà validées . • (i.e. répéter l’historique) • 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 l’analyse Dernier chkpt CRASH A R U

18. Reprise: Phase de l’Analyse • Reconstruire l’état de la base de données au dernier checkpoint (Utiliser les enregistrements du type end_checkpoint). • Scanner le log vers l’avant à 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 n’y est pas encore): • lastLSN de T est maintenant égal au LSN de l’enregistrement • Si l’enregistrement est Commit, changer le statut de T à C, sinon changer le statut à U (i.e. à défaire). • Update : Si la page P affectée n’est 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 l’enregistrement

19. Reprise: Phase REDO • Nous répétons l’historique (le log) afin de reconstruire l’état au moment de la panne: • Refaire tous les changements, ainsi que les CLRs. • Scanner le log vers l’avant à partir de l’enregistrement du log avec le plus petit recLSN dans la table des pages modifiées. Chaque action d’un CLR ou d’un changement LSN est refait, sauf si: • La page affectée n’est 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 l’action du log. • Changer pageLSN à LSN. Aucune journalisation n’est faite.

20. Reprise: Phase UNDO ToUndo={ l | l = lastLSN des transactions perdantes} Répéter: • Choisir le plus grand LSN de l’ensemble 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 à l’ensemble ToUndo • Sinon ce LSN est un changement. Défaire le changement, écrire un CLR, ajouter prevLSN à l’ensemble ToUndo. Jusqu’à ce que ToUndo est vide.

21. RAM Exemple de Reprise LSN LOG 00 05 10 20 30 40 45 50 60 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 prevLSNs Table des transactions lastLSN status Table des pages modifiées recLSN flushedLSN ToUndo

22. RAM Exemple: Panne Durant la Phase UNDO LSN LOG 00,05 10 20 30 40,45 50 60 70 80,85 90 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 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 l’analyse ou la phase REDO? • Comment limiter la quantité de travail durant la phase REDO? • Stocker périodiquement et de manière asynchronique à l’arriè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 l’atomicité et la durabilité. • Utilisation du protocole WAL pour implémenter l’approche VOL/NON FORCAGE. • Les LSNs identifient les enregistrements du log; l’enchainement 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