Anno Architetture dati - DBMS Centralizzati Recovery management Carlo Batini

Riferimenti  Trasparenze parte Recovery manager  Basi di Dati Atzeni et al. - Capitolo 2.1, 2.2  Anche: –Garcia Molina, Ullman, Widom, Database Systems – the complete book, Prentice Hall, 2002

Bufferm Management – Recovery Management – C. Batini e P. Missier– 3 Recovery manager Gestore della affidabilità

Data Base Recovery  Il recovery manager e’ responsabile di –Garantire Atomicita’ –Garantire Persistenza –Realizzare i comandi transazionali fondamentali:  Begin transaction, end transaction, commit work, rollback work  Obiettivo del recovery manager e’ quindi di: –Gestire il rollback di una transazione –Ricostruire uno stato consistente del DB e che rispetti la semantica della transazioni, in seguito a un guasto del DBMS

Organizzazione del materiale  1. Tipi di guasti e politica generale di ripristino  2. Informazioni che il recovery manager deve avere a disposizione per operare –Log –Dump –Checkpoint  3. Operazioni che utilizzano queste informazioni e che sono a disposizione del recovery manager –Undo e Redo  4. Politiche per l’aggiornamento delle informazioni di sistema (log) e della BaseDati da parte del recovery manager

Bufferm Management – Recovery Management – C. Batini e P. Missier– 6 1. Tipi di guasti e politica generale di ripristino

Concetto di Memoria stabile  Memoria resistente ai guasti  E un’astrazione, benche’ tecniche di replicazione su dispositivi fisici multipli possano portare la probabilita’ di perdita di dati vicina allo zero  L’organizzazione fisica puo’ differire a seconda della criticita’ delle applicazioni: –Unita’ nastro –Devices di tipo diverso accoppiati (es un nastro e un disco) –Due unita’ disco replicate – protocolli RAID, Redundant Array of Inexpensive Disks

Tipi di guasti e cause di rollback - 1  Guasti di sistema –System crash, errore hw/sw o di rete (es. Calo tensione): –Errore di sistema o applicativo (della transazione)  Esempio: divisione per zero –Condizioni logiche locali durante l’esecuzione di una transazione (es. assenza di un dato) –Gestione della concorrenza (vedremo piu’ avanti)  Lo scheduler puo’ forzare il rollback e restart di una transazione –Perdita del contenuto del buffer, memoria di massa rimane valida

Tipi di guasti e cause di rollback - 2  Guasti di dispositivo di memorizzazione –Guasto di disco –Problemi “catastrofici”  Incendio  Alluvione  Attentato Perdita fisica di dati su memoria di massa ma non del log (che e’ su memoria stabile)

Le strategie da adottare dipendono dal tipo di guasto  Guasti di sistema: –Perdita del buffer, stato persistente intatto –Problema principale  Atomicita’ –Strategia di recovery:  Tenere memoria sulle operazioni effettuate (log)  Fare periodicamente la “fotografia” della situazione (checkpoint)  Ripercorrere all’indietro la storia dei cambiamenti di stato del DB  E’ necessario disfare (undo) alcune operazioni, ripeterne altre (redo) (vedi oltre per dettagli)

Le strategie da adottare dipendono dal tipo di guasto  Guasti di dispositivo: –Perdita dello stato persistente (perdita dei dischi) –Problema principale  Persistenza –Strategia di recovery:  Memorizzare periodicamente su memoria stabile lo stato della BD ( dump )  Caricare il piu’ recente stato disponibile del DB  Ricostruire lo stato attuale utilizzando il log a partire dal dump

Bufferm Management – Recovery Management – C. Batini e P. Missier– Informazioni disponibili al recovery manager 2.1. Il log di sistema 2.2. Checkpoint 2.3. Dump

2.1 Organizzazione del system log  Il log e’ un file sequenziale che si assume scritto su memoria stabile, per la quale cioe’ non vi possono essere guasti  Registra le attivita’ svolte da ciascuna transazione, in ordine cronologico  Nel log compaiono due tipi di record: –Record di transazione  Informazioni sulle operazioni effettuate dalle transazioni –Record di sistema  Evento di Checkpoint  Evento di Dump

Record di transazione: ci interessano le operazioni di modifica –La struttura dipende dal tipo di operazione –Legenda O=oggetto, AS = After (dopo) State, BS = Before (prima) State Struttura per le varie operazioni –begin, B(T) –insert, I(T,O, AS) –delete, D(T,O,BS) –update, U(T,O,BS,AS) –commit, C(T), o abort, A(T)

Esempio di log B(T1)B(T2) C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…)

2.2 Checkpoint  Lo scopo del checkpoint e’ quello di ricordare l’insieme delle transazioni attive (al momento del checkpoint) T1, …, Tn distinguendole da quelle completate/committed

Esempio di stato delle transazioni al momento del checkpoint dump CK B(T1) B(T2) C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) T1 T2 T3 Completata/ committed Attiva/ uncommitted Deve ancora iniziare

Checkpoint - 1  La primitiva di checkpoint (CK) esegue due operazioni –Per ogni transazione che ha eseguito un commit (committed nel seguito) prima del checkpoint, copia le pagine di buffer su disco (quindi di queste transazioni non dovremo piu’ occuparcene) –Per ogni transazione che ha eseguito un abort prima del checkpoint effettua la procedura di UNDO (vedi seguito) –Successivamente scrive nel log un record CK(T1,…Tn) contenente gli IDentificatori delle transazioni T1,…Tn attive (cioe’ che non hanno eseguito un commit, uncommitted nel seguito) all’atto della esecuzione del checkpoint

Esempio di stato delle transazioni al momento del checkpoint dump CK(T1) B(T1) B(T2) C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) T1 T2 T3 Completata/ Committed Copia su disco Attiva/ Uncommitted Scrive su log l’identificatore Deve ancora Iniziare niente

Checkpoint - 2  Conseguenza: –Per tutte le transazioni T per cui Commit(T) precede CK(T1,…Tn), non e’ necessario fare niente (rieseguire) in caso di guasto  Il checkpoint viene eseguito periodicamente, e registrato nel log

Quali tra queste? dump CK(T1) B(T1) B(T2) C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) T1 T2 T3 Completata/ Committed Copia su disco Attiva/ Uncommitted Scrive su log l’identificatore Deve ancora Iniziare niente

Percio’ la sequenza di checkpoint e’.. –1. Sospende l’esecuzione delle transazioni –2. Scrive su disco le pagine del buffer delle transazioni che hanno fatto il commit –3. Esegue procedura di UNDO per le transazioni terminate con abort –4. Successivamente, scrive il record CK(T1,…Tn) sul log in modo sincrono (force) –4. Riprende l’esecuzione delle transazioni Deve essere sicuro che sia completato il trasferimento Per garantire la persistenza

Esempio di log con checkpoint CK B(T1)B(T2) C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…)

2.3 Dump  Un dump e’ una copia dell’intero stato del DB su memoria stabile  Eseguita offline (nessuna transazione attiva, serve una “fotografia”)  Produce un backup, cioe’ salvataggio su memoria stabile  Scrive (force) un record di dump nel log, che segnala che in quell’istante e’ stata fatta una copia della BD

Esempio di log con checkpoint e dump CK B(T1)B(T2) C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) dump

Record di end  Alcuni sistemi registrano nel log per ogni transazione anche il record di end, che attesta che le operazioni di flush relative alla transazione sono terminate. CK B(T1)B(T2)C(T2) B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) dump Crash END(T2)

Record di end In presenza del record di end, e’ possibile individuare una ulteriore classe di transazioni per le quali non e’ necessario effettuare nessuna azione, ne’ di undo ne’ di redo. CK B(T1)B(T2)C(T2) B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) dump Crash END(T2)

Record di end CK B(T1)B(T2)C(T2) B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) dump Crash END(T2) In genere il record di end non e’ previsto, e noi faremo nel seguito questa assunzione.

Bufferm Management – Recovery Management – C. Batini e P. Missier– 29 Operazioni che utilizzano il log Undo e Redo

Esempio di stato delle transazioni al momento del crash dump CK B(T1) B(T2)C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) T1 T2 T3 Crash

Atomicita’ e persistenza delle transazioni  Per le transazioni che al momento di un guasto sono: –Committed (la transazione si e’ impegnata a eseguire tutte le proprie azioni)  e’ necessario rifare le azioni, per garantire la persistenza  Redo –Uncommitted  e’ necessario disfare le azioni, perchè non e’ noto quali azioni siano state effettuate, ma deve essere garantita la atomicita’  Undo

Undo –Ripristina lo stato di un dato O al tempo precedente l’esecuzione di una operazione –Ripercorre il log all’indietro, assegnando il valore BS “before state” ad ogni dato incontrato nel log –update, delete : assegna il valore BS ad O –insert : cancella O

Redo –Ripristina lo stato di un dato O al tempo successivo l’esecuzione di una operazione –Ripercorre il log in avanti, assegnando il valore AS (“after state”) ad ogni dato incontrato nel log –insert, update :assegna il valore AS ad O –delete : cancella O

A queste aggiungiamo RESUBMIT – La transazione viene risottomessa al Gestore delle transazioni per essere nuovamente eseguita

Bufferm Management – Recovery Management – C. Batini e P. Missier– 35 Politiche per l’aggiornamento del log e della BD da parte del recovery manager

Tre tipi di eventi vanno sequenziati con opportune politiche 1.Scrittura dei record di transazione del log su memoria stabile 2.Scrittura dei record dati su disco 3.Esecuzione della istruzione di commit e memorizzazione nel log

Per semplificare la trattazione ci occupiamo del solo caso record dati su disco vs esecuzione del commit Record dati su disco Esecuzione Commit

Caso record dati su disco vs esecuzione del commit  Per ciascuna delle tre tipologie di operazioni su DB –Update –Insert –Delete  il recovery manager deve seguire delle politiche di esecuzione per la scrittura su disco  Lo faremo per la update

Caso dei record dati su disco e esecuzione del commit e mem. nel log - strategie - 1  Due strategie di scrittura dei valori nella BD  1. Aggiornamento immediato - Le updates vengono scritte su disco immediatamente  2. Aggiornamento differito - Le updates vengono scritte su disco solo dopo il commit della transazione – piu’ efficiente

Esempi delle due politiche Immediata Differita Mista

Modalita’ immediata  Il DB contiene valori AS provenienti da transazioni uncommitted  Richiede Undo delle operazioni di transazioni uncommitted al momento del guasto  Non richiede Redo dumpCKCrash T3 T1 T5 T2 T6 Nulla Undo T4 Undo A Contenuto del log

Modalita’ differita  Il DB non contiene valori AS provenienti da transazioni uncommitted  In caso di abort, non occorre fare nulla  Rende superflua la procedura di Undo  Richiede Redo dumpCKCrash T3 T1 T5 T2 T6 Nulla Redo Nulla T4 Nulla A

Bufferm Management – Recovery Management – C. Batini e P. Missier– 43 Strategie per il recovery

Scopo delle strategie  Garantire atomicita’ e persistenza (durability)  Atomicita’ – le transazioni in corso all’atto del guasto lasciano il DB nello stato iniziale o nello stato finale  Persistenza – Le pagine completate nel buffer ma non ancora trasferite su disco devono essere trasferite permanentemente su disco

Due modalita’  Caso di guasto di sistema  Perdita del contenuto del buffer:  Warm restart o Ripresa a caldo  Guasto di dispositivo  Perdita della memoria di massa:  Cold restart o Ripresa a freddo

Ambito del warm restart o del cold restart CK B(T1)B(T2) C(T2)B(T3) U(T3,…) U(T1,…) U(T2,…) U(T1,…) dump Crash Warm restart Cold restart