Reprise sur panne Undo/Redo PDF
Document Details
Uploaded by Deleted User
Philippe Rigaux
Tags
Summary
These notes detail the process of recovery from system failures in databases, specifically focusing on the techniques to undo and redo operations using logs. They describe checkpoints and how they help to limit recovery operations to recent modifications.
Full Transcript
C018SA-W5-S5 1 Semaine 5 : Reprise sur panne 1. Introduction 2. Lectures et écritures, buffer et disque 3. Première approche 4. Le journal des transactions 5. Algorithmes de reprise sur panne 6. Pannes de disque 2Philippe Rigaux Refaire et défaire En cas de panne légère, l’écrit...
C018SA-W5-S5 1 Semaine 5 : Reprise sur panne 1. Introduction 2. Lectures et écritures, buffer et disque 3. Première approche 4. Le journal des transactions 5. Algorithmes de reprise sur panne 6. Pannes de disque 2Philippe Rigaux Refaire et défaire En cas de panne légère, l’écriture opportuniste a pour conséquences : Des modifications validées qui ne sont pas encore dans la base. Inversement, des modifications non validées qui sont dans la base. À la reprise, il faut donc Refaire (Redo) les transactions validées ; Défaire (Undo) les transactions en cours. Ces deux opérations sont basées sur le journal. 3 Les informations du log On peut reconstituer, à partir du log la liste LV des transactions validées : on trouve un commit dans le log la liste LA des transactions actives ou annulées : pas de commit dans le log l’image après (new_val) et l’image avant (old_val) pour chaque transaction. Ces informations sont nécessaires et suffisantes pour la reprise sur panne 4 Défaire Les transactions non validées, LA , celles qui n’ont pas de commit dans le journal L’algorithme de Undo prend chaque T de LA , dans l’ordre inverse d’exécution. Puis, pour chaque write(T, x, old_val, new_val), on écrit old_val dans x. 5 Refaire Les transactions validées, LV : pour lesquelles on trouve un commit(T) dans le log L’algorithme de Redo prend chaque T de LV , dans l’ordre d’exécution. Puis, pour chaque write(T, x, old_val, new_val), on écrit new_val dans x. Et si la reprise subit une panne ? Il faut recommencer : le Redo est idempotent. 6 L’algorithme de reprise Undo/Redo C’est le plus général. on constitue la liste des transactions actives LA et la liste des transactions validées LV au moment de la panne ; on défait les écritures de LA ⇒ attention les annulations se font dans l’ordre inverse de l’exécution initiale ; on refait les écritures de LV avec le journal. 7 À propos des checkpoints En cas de panne, il faudrait en principe refaire toutes les transactions du journal, depuis l’origine de la création de la base. Un checkpoint écrit sur disque tous les blocs modifiés, ce qui garantit que les données validées par commit sont dans la base. 8 Résumé : reprise sur panne Undo/Redo Retenir : Le log contient la liste des transactions validées ; la liste des transactions annulées. Une reprise ne prend en compte que celles depuis le dernier checkpoint. La reprise consiste à parcourir le log et à défaire les transactions annulées, puis refaire les transactions validées. Schéma général : variantes dans les systèmes, voir exercices. 9 Résumé : reprise sur panne Undo/Redo Retenir : Le log contient la liste des transactions validées ; la liste des transactions annulées. Une reprise ne prend en compte que celles depuis le dernier checkpoint. La reprise consiste à parcourir le log et à défaire les transactions annulées, puis refaire les transactions validées. Schéma général : variantes dans les systèmes, voir exercices. Merci ! 9