Cours 5: Récupération Nguyen Tuanloc

But Reprise BD après un accident Principe: Matériel Logiciel Journalisation: enregistrer toutes les transactions effectuées sur la base Restaurer la base

Pannes Erreurs dans les programmes d’application (transactions) Erreurs dans l’entrée des données Erreurs d’enregistrement sur disques et crash matériels Catastrophes Pannes (bugs) et crash du logiciel

Erreurs dans les transactions Erreurs prévues : prises en charge par le programme d’application Erreurs imprévues : arrêter la transaction (abort) et défaire ce qu’elle a pu faire (rollback)

Erreurs dans l’entrée des données Erreurs détectables : par les contraintes d’intégrité par les triggers Erreurs non détectables : valeurs vraisemblables mais incorrectes (par exemple, année de naissance 1978 au lieu de 1987)

Erreurs disques Utilisation des bits de parité pour vérifier les enregistrements au niveau secteur Crash de la tête de lecture :

Catastrophe Incendie, inondation, explosion Redondance

Crash du logiciel Perte du contenu de la mémoire En cours de: Journalisation Reprise sur panne

Solution

Opérations: Input (x): donnée x  mémoire Output (x): donnée x  disk Read (x,t): do input(x) si nécessaires t  valeur x Write (x,t): do input(x) si nécessaires valeur x  t

Key problem Unfinished transaction Example Constraint: A=B T1: A  A  2 B  B  2

T1: Read (A,t); t  t2 Write (A,t); Read (B,t); t  t2 Write (B,t); Output (A); Output (B); 16 failure! A: 8 B: 8 A: 8 B: 8 16 memoire disque

Atomicité (+ cohérence, isolation, durabilité)

ATOMICITE DES TRANSACTIONS PROBLEME APRES UNE PANNE, UNE TRANSACTION DOIT ETRE : --> SOIT TOTALEMENT EXECUTEE --> SOIT PAS DU TOUT SOLUTION EXECUTION D'UNE ACTION SPECIALE : COMMIT ou VALIDATION EN FIN DE TRANSACTION, DANS LE BUT DE RENDRE EFFECTIVES TOUTES LES MISES A JOUR REALISEES PAR LA TRANSACTION SUR LA BASE

REVENIR A UN ETAT COHERENT DE LA BASE Reprise sur panne PROBLEME REVENIR A UN ETAT COHERENT DE LA BASE SOLUTIONS DEFAIRE UNE TRANSACTION NON VALIDEE --> UNDO REFAIRE UNE TRANSACTION VALIDEE --> REDO OUTILS JOURNALISATION DES TRANSACTIONS COPIE D'UN ETAT COHERENT DE LA BASE

Undo /Redo Journal Écriture dans journal Sauvegarde Mise à jour de la base Point de reprise

Undo logging (immediate modification)

Undo logging (Immediate modification) T1: Read (A,t); t  t2 A=B Write (A,t); Read (B,t); t  t2 Write (B,t); Output (A); Output (B); 16 <T1, start> <T1, A, 8> A:8 B:8 A:8 B:8 16 <T1, B, 8> 16 <T1, commit> disk memory log

One “complication” Log is first written in memory Not written to disk on every action memory DB Log A: 8 B: 8 16 BAD STATE # 1 A: 8 16 B: 8 16 Log: <T1,start> <T1, A, 8> <T1, B, 8>

One “complication” Log is first written in memory Not written to disk on every action memory DB Log A: 8 B: 8 16 BAD STATE # 2 A: 8 16 B: 8 16 Log: <T1,start> <T1, A, 8> <T1, B, 8> <T1, commit> ... <T1, B, 8> <T1, commit>

Undo logging rules (1) For every action generate undo log record (containing old value) (2) Before x is modified on disk, log records pertaining to x must be on disk (3) Before commit is flushed to log, all writes of transaction must be reflected on disk

Recovery rules: Undo logging For every Ti with <Ti, start> in log: - If <Ti,commit> or <Ti,abort> in log, do nothing - Else For all <Ti, X, v> in log: write (X, v) output (X ) Write <Ti, abort> to log IS THIS CORRECT??

Recovery rules: Undo logging (1) Let S = set of transactions with <Ti, start> in log, but no <Ti, commit> (or <Ti, abort>) record in log (2) For each <Ti, X, v> in log, in reverse order (latest  earliest) do: - if Ti  S then - write (X, v) - output (X) (3) For each Ti  S do - write <Ti, abort> to log

Redo logging (deferred modification) T1: Read(A,t); t t2; write (A,t); Read(B,t); t t2; write (B,t); Output(A); Output(B) 16 <T1, start> <T1, A, 16> <T1, B, 16> <T1, commit> A: 8 B: 8 output 16 A: 8 B: 8 mémoire BD LOG

Redo logging rules (1) For every action, generate redo log record (containing new value) (2) Before X is modified on disk (DB), all log records for transaction that modified X (including commit) must be on disk (3) Flush log at commit

Recovery rules: Redo logging For every Ti with <Ti, commit> in log: For all <Ti, X, v> in log: Write(X, v) Output(X) IS THIS CORRECT??

Recovery rules: Redo logging (1) Let S = set of transactions with <Ti, commit> in log (2) For each <Ti, X, v> in log, in forward order (earliest  latest) do: - if Ti  S then Write(X, v) Output(X) optional

Recovery is very, very SLOW ! Redo log: First T1 wrote A,B Last Record Committed a year ago Record (1 year ago) --> STILL, Need to redo after crash!! ... ... ... Crash

Solution: Checkpoint (simple version) Periodically: (1) Do not accept new transactions (2) Wait until all transactions finish (3) Flush all log records to disk (log) (4) Flush all buffers to disk (DB) (do not discard buffers) (5) Write “checkpoint” record on disk (log) (6) Resume transaction processing

Example: what to do at recovery? Redo log (disk): <T1,A,16> <T1,commit> Checkpoint <T2,B,17> <T2,commit> <T3,C,21> Crash ... ... ... ... ... ...

Key drawbacks: Undo logging: difficile pour stocker tous les backup Redo logging: difficile pour stocker toutes les modifications avant Commit

Solution: undo/redo logging! Update  <Ti, Xid, New X val, Old X val> page X

Rules Page X can be flushed before or after Ti commit Log record flushed before corresponding updated page Flush at commit (log only)

Non-quiesce checkpoint L O G for undo dirty buffer pool pages flushed Start-ckpt active TR: Ti,T2,... end ckpt ... ... ... ...

Examples what to do at recovery time? no T1 commit L O G ... T1,- a ... Ckpt T1 ... Ckpt end ... T1- b  Undo T1 (undo a,b)

Example L O G  Redo T1: (redo b,c) ... T1 a ... T1 ... T1 b ... ckpt- ckpt-s T1 ... T1 b ... ckpt- end ... T1 c ... T1 cmt ...  Redo T1: (redo b,c)

Recovery process: Backwards pass (end of log  latest checkpoint start) construct set S of committed transactions undo actions of transactions not in S Undo pending transactions follow undo chains for transactions in (checkpoint active list) - S Forward pass (latest checkpoint start  end of log) redo actions of S transactions backward pass start check- point forward pass

Real world actions E.g., dispense cash at ATM Ti = a1 a2 …... aj …... an $

Solution (1) execute real-world actions after commit (2) try to make idempotent

ATM Give$$ (amt, Tid, time) lastTid: time: give(amt) $

Media failure A: 16 Solution: Make copies of data!

Example 1 Triple modular redundancy Keep 3 copies on separate disks Output(X) --> three outputs Input(X) --> three inputs + vote X3 X1 X2

Example #2 Redundant writes, Single reads Keep N copies on separate disks Output(X) --> N outputs Input(X) --> Input one copy - if ok, done - else try another one  Assumes bad data can be detected

Example #3: DB Dump + Log backup active database database log If active database is lost, restore active database from backup bring up-to-date using redo entries in log

When can log be discarded? db dump last needed undo check- point log time not needed for media recovery not needed for undo after system failure not needed for redo after system failure

Summary Consistency of data One source of problems: failures - Logging - Redundancy Another source of problems: Data Sharing..... next

Annexe

Annexe 2

FIABILITE

ATOMICITE DES TRANSACTIONS PROBLEME APRES UNE PANNE, UNE TRANSACTION DOIT ETRE : --> SOIT TOTALEMENT EXECUTEE --> SOIT PAS DU TOUT SOLUTION EXECUTION D'UNE ACTION SPECIALE : COMMIT ou VALIDATION EN FIN DE TRANSACTION, DANS LE BUT DE RENDRE EFFECTIVES TOUTES LES MISES A JOUR REALISEES PAR LA TRANSACTION SUR LA BASE

REVENIR A UN ETAT COHERENT DE LA BASE REPRISE APRES PANNE PROBLEME REVENIR A UN ETAT COHERENT DE LA BASE SOLUTIONS DEFAIRE UNE TRANSACTION NON VALIDEE --> UNDO REFAIRE UNE TRANSACTION VALIDEE --> REDO OUTILS JOURNALISATION DES TRANSACTIONS COPIE D'UN ETAT COHERENT DE LA BASE

CLASSIFICATION DES REPRISES REPRISE TRANSACTION ABANDON D'UNE TRANSACTION EN EXECUTION ORDONNE PAR --> LA TRANSACTION (ABORT) --> LE SGBD POUR UN PROBLEME DE CONCURRENCE (DEADLOCK, ...) OU VIOLATION DE CONTRAINTES REPRISE A CHAUD (SYSTEME) ==> PERTE MEMOIRE CENTRALE ==> ABANDON DE TOUTES LES TRANSACTIONS EN EXECUTION REPRISE A FROID (DISQUE) ==> PERTE MEMOIRE SECONDAIRE ==> RECONSTRUIRE LA BASE

JOURNALISATION  STOCKER SUR UN SUPPORT DE MEMORISATION FIABLE, DIFFERENT DE CELUI DE LA BASE, LES INFORMATIONS NECESSAIRES POUR DEFAIRE ET REFAIRE LES TRANSACTIONS JOURNAL DES IMAGES AVANT CONTIENT LES VALEURS DES DONNEES DE LA BASE AVANT MISE A JOUR PAR UNE TRANSACTION JOURNAL DES IMAGES APRES CONTIENT LES VALEURS DES DONNEES DE LA BASE APRES MISE A JOUR PAR UNE TRANSACTION POUR CHAQUE TRANSACTION --> MARQUE DE DEBUT --> MARQUE DE FIN (commit / abort)

ECRITURE DANS LE JOURNAL MISE A JOUR D'UNE DONNEE DE LA BASE POUR CHAQUE MISE A JOUR D'UNE DONNEE X DE LA BASE PAR UNE TRANSACTION T : 1 - ECRIRE DANS LE JOURNAL L'IDENTIFIANT DE LA TRANSACTION T LA VALEUR AVANT DE X, APRES DE X 2 - ECRIRE DANS LA BASE LA VALEUR DE X MODIFIEE (VALEUR APRES)

TYPES DE JOURNALISATION PHYSIQUE LES ENREGISTREMENTS JOURNAUX SONT DES COPIES DE PAGES OU D'OBJETS AVANT ET / OU APRES MODIFICATION - COUTEUX EN TEMPS DE RECOPIE ET EN PLACE MEMOIRE - OPERATION DE JOURNALISATION NE SONT PAS COMMUTABES (INTERDICTION DE RELACHER PREMATUREMENT UN VERROU POUR GAGNER DU PARALLELISME)

TYPES DE JOURNALISATION (2) LOGIQUE LES ENREGISTREMENTS JOURNAUX SONT DES LIBELLES D'OPERATIONS SUR LA BASE - SEULES PEUVENT ETRE JOURNALISEES DES OPERATIONS POSSEDANT UNE OPERATION INVERSE - DOIT TOUJOURS S'APPUYER SUR UNE VERSION COHERENTE DES OBJETS JOURNALISES (PROPAGATION ATOMIQUE DES MISES A JOUR)

UTILISATION DU JOURNAL LA LECTURE, A PARTIR DE LA FIN, DU JOURNAL DES IMAGES AVANT PERMET DE DEFAIRE TOUTE TRANSACTION NON VALIDEE LA LECTURE, A PARTIR DU DEBUT, DU JOURNAL DES IMAGES APRES PERMET DE REFAIRE TOUTE TRANSACTION VALIDEE

UTILISATION DU JOURNAL (2) Après une panne TRANSACTION --> DEFAIRE LA TRANSACTION T EN APPLIQUANT LE JOURNAL DES IMAGES AVANT, A PARTIR DE LA FIN , JUSQU'A LA RENCONTRE DE LA MARQUE DU DEBUT DE LA TRANSACTION T --> RELANCER L'EXECUTION DE LA TRANSACTION T

SAUVEGARDE DEFINITION POINT DE SAUVEGARDE COPIE DE LA BASE SUR UN SUPPORT FIABLE DIFFERENT DE CELUI DE LA BASE (EN GENERAL, IL S'AGIT D'UNE BANDE MAGNETIQUE) - PAS DE TRANSACTION EN EXECUTION - BASE COHERENTE POINT DE SAUVEGARDE PROPAGER SUR DISQUE UN ETAT COHERENT RECENT DE LA BASE ET DES JOURNAUX (gain de temps à la reprise après panne) Pb : Reporter sur l'archive un état cohérent sans arrêter toutes les activités - Niveau transaction (aucune active) - Niveau action (en cours de transaction)

DEFAIRE TOUTES LES TRANSACTIONS NON VALIDEES A L'AIDE DU JOURNAL AVANT REPRISE A CHAUD DEFAIRE TOUTES LES TRANSACTIONS NON VALIDEES A L'AIDE DU JOURNAL AVANT ( STRATEGIE DO - UNDO )

RECHARGER LA BASE AVEC LA DERNIERE VERSION COHERENTE SAUVEGARDEE REPRISE A FROID  RECHARGER LA BASE AVEC LA DERNIERE VERSION COHERENTE SAUVEGARDEE REFAIRE TOUTES LES TRANSACTIONS VALIDEES ENTRE LE DERNIER POINT DE SAUVEGARDE ET LA PANNE, EN APPLIQUANT LE JOURNAL DES IMAGES APRES AUX SEULES TRANSACTIONS VALIDEES

MISE A JOUR DE LA BASE EN PLACE SONT REALISEES AU FUR ET A MESURE DE L'EXECUTION DE LA TRANSACTION (C'EST L'HYPOTHESE FAITE JUSQU'ALORS) Vulnérable aux pannes, non atomique, ne supporte pas la journalisation logique DIFFEREE SONT STOCKEES DANS L'ESPACE DE TRAVAIL DE LA TRANSACTION ET REPERCUTEES SUR LA BASE UNIQUEMENT A LA FIN DE LA TRANSACTION INDIRECTE LA PAGE MODIFIEE EST REPORTEE SUR UN NOUVEAU BLOC DISQUE (atomique) (exemple : basculement des tables des pages pour la technique des pages ombres)

VALIDATION DEUX PHASES HYPOTHESE : MISE A JOUR DIFFEREE VALIDATION D'UNE TRANSACTION PHASE 1 : ECRITURE DANS LE JOURNAL --> ECRITURE DES DONNEES MISES A JOUR (IMAGES APRES) --> ECRITURE MARQUE "PRET A COMMETTRE" PHASE 2 : ECRITURE DANS LA BASE --> ECRITURE DES DONNEES MISES A JOUR DANS LA BASE --> ECRITURE DE LA MARQUE "COMMETTRE" DANS LE JOURNAL

ABANDON D'UNE TRANSACTION HYPOTHESE (MISE A JOUR DIFFEREE) PANNE AVANT "PRET A COMMETTRE" DEFAIRE LA TRANSACTION NE DEMANDE AUCUNE ACTION, CAR LES MISES A JOUR EFFECTUEES PAR LA TRANSACTION N'ONT PAS ENCORE ETE REPERCUTEES SUR LA BASE PANNE ENTRE "PRET A COMMETTRE" ET "COMMETTRE" LA TRANSACTION EST REFAITE AVEC LES IMAGES APRES ENREGISTREES DANS LE JOURNAL

ETAT COHERENT DE LA BASE CREE PERIODIQUEMENT PAR LE SYSTEME POINT DE REPRISE DEFINITION ETAT COHERENT DE LA BASE CREE PERIODIQUEMENT PAR LE SYSTEME OPERATIONS 1 -INTERRUPTION DES TRANSACTIONS EN EXECUTION 2 -MARQUE DE POINT DE REPRISE DANS LE JOURNAL, AVEC LA LISTE DE TOUTES LES TRANSACTIONS EN COURS  3 -VIDAGE DU TAMPON E/S DU JOURNAL 4 -VIDAGE DU TAMPON E/S DE LA BASE BASE COHERENTE = BASE + JOURNAL AVANT

DIFFERENCE AVEC POINT DE SAUVEGARDE ==> COHERENCE PHYSIQUE POINT DE REPRISE ==> COHERENCE LOGIQUE OBJECTIF DES POINTS DE REPRISE ESPACER LA DUREE ENTRE DEUX POINTS DE SAUVEGARDE. UNE SAUVEGARDE COMPLETE DE LA BASE EST UNE OPERATION LONGUE ET COUTEUSE REMARQUE LA GESTION DE POINTS DE REPRISE SYSTEME MODIFIE UN PEU LES TECHNIQUES DE REPRISE A CHAUD ET DE REPRISE A FROID