Cours 5: Récupération Nguyen Tuanloc.

Présentation au sujet: "Cours 5: Récupération Nguyen Tuanloc."— Transcription de la présentation:

1 Cours 5: Récupération Nguyen Tuanloc

2 But Reprise BD après un accident Principe: Matériel Logiciel
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 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

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

15 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

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

17 Undo logging (immediate modification)

18 Undo logging (Immediate modification)
T1: Read (A,t); t  t 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

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

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

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

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 Example: what to do at recovery?
Redo log (disk): <T1,A,16> <T1,commit> Checkpoint <T2,B,17> <T2,commit> <T3,C,21> 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 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)

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

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 1 Triple 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 active database 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?
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

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

51 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

52 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

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

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

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

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

57 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

58 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

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

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

61 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

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

63 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

64 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

65 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

66 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