La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Cours 5: Récupération Nguyen Tuanloc. But Reprise BD après un accident Matériel Logiciel Principe: Journalisation: enregistrer toutes les transactions.

Présentations similaires


Présentation au sujet: "Cours 5: Récupération Nguyen Tuanloc. But Reprise BD après un accident Matériel Logiciel Principe: Journalisation: enregistrer toutes les transactions."— Transcription de la présentation:

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 dapplication (transactions) Erreurs dans lentrée des données Erreurs denregistrement 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 dapplication Erreurs imprévues : arrêter la transaction (abort) et défaire ce quelle a pu faire (rollback)

5 Erreurs dans lentrée des données Erreurs détectables : par les contraintes dinté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 ExampleConstraint: A=B T 1 : A A 2 B B 2

12 T 1 :Read (A,t); t t2 Write (A,t); Read (B,t); t t2 Write (B,t); Output (A); Output (B); A: 8 B: 8 A: 8 B: 8 memoire disque 16 failure!

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 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 T 1 :Read (A,t); t t2 A=B Write (A,t); Read (B,t); t t2 Write (B,t); Output (A); Output (B); A:8 B:8 A:8 B:8 memory disk log Undo logging (Immediate modification)

19 One complication Log is first written in memory Not written to disk on every action memory DB Log A: 8 16 B: 8 16 Log: A: 8 B: 8 16 BAD STATE # 1

20 One complication Log is first written in memory Not written to disk on every action memory DB Log A: 8 16 B: 8 16 Log: A: 8 B: 8 16 BAD STATE # 2...

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 in log: - If or in log, do nothing - Else For all in log: write (X, v) output (X ) Write to log IS THIS CORRECT??

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

24 Redo logging (deferred modification) T 1: Read(A,t); t t2; write (A,t); Read(B,t); t t2; write (B,t); Output(A); Output(B) A: 8 B: 8 A: 8 B: 8 mémoire BD LOG 16 output 16

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 For every Ti with in log: For all in log: Write(X, v) Output(X) Recovery rules: Redo logging IS THIS CORRECT??

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

28 Recovery is very, very SLOW ! Redo log: FirstT1 wrote A,BLast RecordCommitted a year agoRecord (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): Checkpoint 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 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 undodirty 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 T 1,- a... Ckpt T 1... Ckpt end... T1-bT1-b Undo T 1 (undo a,b)

36 Example LOGLOG... T1aT1a T1bT1b T1cT1c T 1 cmt... ckpt- end ckpt-s T 1 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 forward pass start check- point

38 Real world actions E.g., dispense cash at ATM Ti = a 1 a 2 …... a j …... a n $

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

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

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

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? check- point db dump last needed undo not needed for media recovery not needed for undo after system failure not needed for redo after system failure log time

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 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 COHERENTDE 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 LESTRANSACTIONS 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 LATRANSACTION 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 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 REPRISE A CHAUD DEFAIRE TOUTES LES TRANSACTIONS NON VALIDEES A L'AIDE DU JOURNAL AVANT ( STRATEGIE DO - UNDO )

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


Télécharger ppt "Cours 5: Récupération Nguyen Tuanloc. But Reprise BD après un accident Matériel Logiciel Principe: Journalisation: enregistrer toutes les transactions."

Présentations similaires


Annonces Google