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?

plantage! 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).

T1T2T3T4T5

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.

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 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

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. C’est 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 LogTypes d’enregistrements: Update Commit Abort End (signifie la fin de

Commit ou Abort) Enregistrements

compensatoires (Compensation Log Records -

CLRs) Pour les actions UNDO

prevLSNtransIDtype

lengthpageID

offsetbefore-imageafter-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 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

transactions et 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

Survol des Lieux de Stockage des Structures

DB

Pages de données:chacune avec un pageLSN

Table des transactionslastLSNstatus

Table des pages modifiées

recLSN

flushedLSN

RAM

prevLSNtransIDtype

lengthpageID

offsetbefore-imageafter-image

LogRecords

LOG

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 crashPlus 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 UNDOToUndo={ 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

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

00

05

10

20

30

40

45

50

60

Table des transactionslastLSNstatus

Table des pages modifiéesrecLSN

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 LOG00,05

10

20

30

40,45

50

60

70

80,85

90

ToUndo

undonextLSN

RAM

Table des transactionslastLSNstatus

Table des pages modifiéesrecLSN

flushedLSN

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