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