Cours 5: Récupération

1. Cours 5: Récupération Nguyen Tuanloc

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

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

4. 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)

5. 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)

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

7. Catastrophe • Incendie, inondation, explosion • Redondance

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

9. Solution

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

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

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

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

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

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

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

17. Undo logging (immediate modification)

18. <T1, start> <T1, A, 8> 16 16 16 16 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); A:8 B:8 A:8 B:8 <T1, B, 8> <T1, commit> disk memory log

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

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

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

22. 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??

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

24. <T1, start> <T1, A, 16> <T1, B, 16> <T1, commit> output 16 16 16 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) A: 8 B: 8 A: 8 B: 8 BD mémoire LOG

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

26. 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??

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

47. Annexe

48. Annexe 2

49. FIABILITE

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