cours 5: récupération
DESCRIPTION
Cours 5: Récupération. Nguyen Tuanloc. But. Reprise BD après un accident Matériel Logiciel Principe: Journalisation: enregistrer toutes les transactions effectuées sur la base Restaurer la base. Pannes. Erreurs dans les programmes d’application (transactions) - PowerPoint PPT PresentationTRANSCRIPT
Cours 5: Récupération
Nguyen Tuanloc
But Reprise BD après un accident
Matériel Logiciel
Principe: 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 t2Write (A,t);Read (B,t); t t2Write (B,t);Output (A);Output (B);
A: 8B: 8
A: 8B: 8
memoire disque
1616
16
failure!
Atomicité (+ cohérence, isolation, durabilité)
ATOMICITE DES TRANSACTIONS PROBLEME
APRES UNE PANNE, UNE TRANSACTION DOIT ETRE :
--> SOIT TOTALEMENT EXECUTEE--> SOIT PAS DU TOUT
SOLUTIONEXECUTION 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
Reprise sur panne PROBLEME
REVENIR A UN ETAT COHERENT DE LA BASE
SOLUTIONSDEFAIRE 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)
T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);Output (A);Output (B);
A:8B:8
A:8B:8
memory disk log
Undo logging (Immediate modification)
1616
<T1, start><T1, A, 8>
<T1, commit>16 <T1, B, 8>
16
One “complication” Log is first written in memory Not written to disk on every action
memory
DB
LogA: 8 16B: 8 16Log:<T1,start><T1, A, 8><T1, B, 8>
A: 8B: 8
16BAD STATE
# 1
One “complication” Log is first written in memory Not written to disk on every action
memory
DB
Log
A: 8 16B: 8 16Log:<T1,start><T1, A, 8><T1, B, 8><T1, commit>
A: 8B: 8
16BAD STATE
# 2
<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 beon disk
(3) Before commit is flushed to log, allwrites 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 t2; write (A,t); Read(B,t); t t2; write (B,t);
Output(A); Output(B)
A: 8B: 8
A: 8B: 8
mémoire BD LOG
1616
<T1, start><T1, A, 16><T1, B, 16>
<T1, commit>
output16
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 thatmodified X (including commit)
must be on disk
(3) Flush log at commit
For every Ti with <Ti, commit> in log: For all <Ti, X, v> in log:
Write(X, v)Output(X)
Recovery rules: Redo logging
IS THIS CORRECT??
(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 rules: Redo logging
Recovery is very, very
SLOW !Redo log:
First T1 wrote A,B LastRecord 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,1
6>
<T1
,com
mit
>
Ch
eck
poin
t
<T2
,B,1
7>
<T2
,com
mit
>
<T3
,C,2
1>
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 orafter Ti commit
Log record flushed before corresponding updated page
Flush at commit (log only)
Non-quiesce checkpoint
LOG
for undo dirty buffer
pool pagesflushed
Start-ckptactive TR:
Ti,T2,...
endckpt
.........
...
Examples what to do at recovery time?
no T1 commit
LOG
T1,-a
...CkptT1
...Ckptend
...T1-b
...
Undo T1 (undo a,b)
ExampleLOG
...T1
a... ...
T1
b... ...
T1
c...
T1
cmt...
ckpt-end
ckpt-sT1
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
forward passstart
check-point
Real world actions
E.g., dispense cash at ATMTi = a1 a2 …... aj …... an
$
Solution
(1) execute real-world actions after commit(2) try to make idempotent
ATMGive$$(amt, Tid, time)
$
give(amt)
lastTid:
time:
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
X1 X2 X3
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
backupdatabase
activedatabase
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?
check-point
dbdump
lastneededundo
not needed formedia recovery
not needed for undoafter system failure
not needed forredo after system failure
log
time
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
SOLUTIONEXECUTION 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
REPRISE APRES PANNE PROBLEME
REVENIR A UN ETAT COHERENT DE LA BASE
SOLUTIONSDEFAIRE UNE TRANSACTION NON
VALIDEE--> UNDO
REFAIRE UNE TRANSACTION VALIDEE--> REDO
OUTILSJOURNALISATION DES
TRANSACTIONSCOPIE D'UN ETAT COHERENT DE LA BASE
CLASSIFICATION DES REPRISES
REPRISE TRANSACTIONABANDON 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 AVANTCONTIENT LES VALEURS DES DONNEES DE LA BASE AVANT
MISE A JOUR PAR UNE TRANSACTION
JOURNAL DES IMAGES APRESCONTIENT 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
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 SAUVEGARDEPROPAGER 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)
REPRISE A CHAUD DEFAIRE TOUTES LES TRANSACTIONS NON
VALIDEES A L'AIDE DU JOURNAL AVANT( STRATEGIE DO - UNDO )
T1 T2 C1 T3 T2 C3 T4
PANNE
T2 et T4 non validées-
- T1 et T3 validées (commises)
BD
cohérente
BD
non
cohérente
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
T1 T2 C1 T3 T2 C3 T4
PANNE
T2 et T4 non validées-
- T1 et T3 validées (commises)
BD
cohérente
BD
cohérente
POINTSAUVEGARDE
copie
BD
MISE A JOUR DE LA BASE EN PLACESONT 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
DIFFEREESONT STOCKEES DANS L'ESPACE DE TRAVAIL DE LA
TRANSACTION ET REPERCUTEES SUR LA BASE UNIQUEMENT A LA FIN DE LA TRANSACTION
INDIRECTELA 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 TRANSACTIONPHASE 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
POINT DE REPRISE
DEFINITIONETAT COHERENT DE LA BASE CREE PERIODIQUEMENT PAR LE
SYSTEME
OPERATIONS1 -INTERRUPTION DES TRANSACTIONS EN EXECUTION2 -MARQUE DE POINT DE REPRISE DANS LE JOURNAL, AVEC LA
LISTE DE TOUTES LES TRANSACTIONS EN COURS 3 -VIDAGE DU TAMPON E/S DU JOURNAL4 -VIDAGE DU TAMPON E/S DE LA BASE
BASE COHERENTE=
BASE + JOURNAL AVANT
DIFFERENCE AVEC POINT DE SAUVEGARDE
POINT DE SAUVEGARDE ==> COHERENCE PHYSIQUE
POINT DE REPRISE==> COHERENCE LOGIQUE
OBJECTIF DES POINTS DE REPRISEESPACER LA DUREE ENTRE DEUX POINTS DE SAUVEGARDE.
UNE SAUVEGARDE COMPLETE DE LA BASE EST UNE OPERATION LONGUE ET COUTEUSE
REMARQUELA GESTION DE POINTS DE REPRISE SYSTEME MODIFIE UN
PEU LES TECHNIQUES DE REPRISE A CHAUD ET DE REPRISE A FROID