Corso di Basi di Dati Gestione delle Transazioni

Corso di Basi di Dati Gestione delle Transazioni Home page del corso: http: //www. cs. unibo. it/~difelice/dbsi/

Gestione delle Transazioni Le transazioni rappresentano unità di lavoro elementare (insiemi di istruzioni SQL) che modificano il contenuto di una base di dati. start transaction update Salari. Impiegati set conto=conto*1. 2 where (Codice. Impiegato = 123) commit work Le transazioni sono comprese tra una start transaction ed una commit/ rollback

Gestione delle Transazioni Le transazioni rappresentano unità di lavoro elementare (insiemi di istruzioni SQL) che modificano il contenuto di una base di dati. start transaction update Salari. Impiegati set conto=conto-10 where (Codice. Impiegato = 123) if conto >0 commit work; else rollback work Le transazioni sono comprese tra una start transaction ed una commit/ rollback

Gestione delle Transazioni PROPRIETA’ ACIDE DELLE TRANSAZIONI Ø Atomicità La transazione deve essere eseguita con la regola del “tutto o niente”. Ø Consistenza La transazione deve lasciare il DB in uno stato consistente, eventuali vincoli di integrità non devono essere violati. Ø Isolamento L’esecuzione di una transazione deve essere indipendente dalle altre. Ø Persistenza L’effetto di una transazione che ha fatto commit work non deve essere perso.

Gestione delle Transazioni Gestione delle transazioni Gestione della concorrenza Gestione dell’affidabilita’ DB Gestore dell’affidabilità garantisce atomicità e persistenza … COME? Usando log e checkpoint. Gestore della concorrenza garantisce l’isolamento in caso d esecuzione concorrente di piu’ transazioni.

Gestione delle Transazioni In un sistema reale, le transazioni vengono eseguite in concorrenza per ragioni di efficienza / scalabilità. … Tuttavia, l’esecuzione concorrente determina un insieme di problematiche devono essere gestite …T 1= Read(x); x=x+1; Write(x); Commit Work T 2= Read(x); x=x+1; Write(x); Commit Work Se x=3, al termine delle due transazioni x vale 5 (esecuzione sequenziale) … cosa accade in caso di esecuzione concorrente?

Gestione delle Transazioni Problema 1: Perdita di Aggiornamento Transazione 1 (T 1) Transazione 2 (T 2) Read(x) x=x+1 Write(x) Commit work T 1 scrive 4 Write(x) Commit work T 2 scrive 4

Gestione delle Transazioni Problema 2: Lettura sporca Transazione 1 (T 1) Transazione 2 (T 2) Read(x) x=x+1 Write(x) Read(x) Commit work Rollback work T 2 legge 4!

Gestione delle Transazioni Problema 3: Letture inconsistenti T 1 legge 3! Transazione 1 (T 1) Transazione 2 (T 2) Read(x) x=x+1 Write(x) Commit work T 1 legge 4! Read(x) Commit work

Gestione delle Transazioni Problema 4: Aggiornamento Fantasma Vincolo: x+y+z deve essere = a 1000 Transazione 1 (T 1) Transazione 2 (T 2) Read(x) Read(y) y=y-100 Read(z) z=z+100 Write(y), Write(z) Commit work Vincolo violato!! Read(z) s=x+y+z; commit work

Gestione delle Transazioni Date un insieme di transazioni T 1, T 2, Tn, di cui ciascuna formata da un certo insieme di operazioni di scrittura (wi) e lettura (ri): Es. T 1=r 1(x) r 1(y) r 1(z) w 1(y) … Si definisce schedule la sequenza di operazioni di lettura/scrittura di tutte le transazioni così come eseguite sulla base di dati: r 1(x) r 2(y) r 1(y) w 4(y) w 2(z) …

Gestione delle Transazioni Uno schedule S si dice seriale se le azioni di ciascuna transazione appaiono in sequenza, senza essere inframezzate da azioni di altre transazioni. S={T 1, T 2, … Tn} Schedule seriale ottenibile se: (i) Le transazioni sono eseguite uno alla volta (scenario non realistico) (ii) Le transazioni sono completamente indipendenti l’una dall’altra (improbabile)

Gestione delle Transazioni Uno schedule S si dice serializzabile se produce lo stesso risultato di un qualunque scheduler seriale S’ delle stesse transazioni. CLASSI Schedule Serializzabili Schedule Seriali Schedule

Gestione delle Transazioni Come implementare il controllo della concorrenza? I DMBS commerciali usano il meccanismo dei lock per poter effettuare una qualsiasi operazioni di lettura/scrittura su una risorsa (tabella o valore di una cella), è necessario aver precedentemente acquisito il controllo (lock) sulla risorsa stessa. Ø Lock in lettura (accesso condiviso) Ø Lock in scrittura (mutua esclusione)

Gestione delle Transazioni Su ogni lock possono essere definite due operazioni: AZIONE Ø Richiesta del lock in lettura/scrittura. Ø Rilascio del lock (unlock) acquisito in precedenza. STATO DELLA RISORSA Libero r_locked w_locked r_lock OK/r_locked NO/w_locked w_lock OK/w_locked NO/r_locked NO/w_locked unlock Errore OK/dipende OK/libero

Gestione delle Transazioni Lock Manager componente del DBMS responsabile di gestire i lock alle risorse del DB, e di rispondere alle richieste delle transazioni. STRUTTURE DATI del LOCK MANAGER Per ciascun oggetto x del DBMS: State(x) stato dell’oggetto (libero/r_locked/w_locked) Active(x) lista transazioni attive sull’oggetto Queued(x) lista transazioni bloccate sull’oggetto

Gestione delle Transazioni Lock Manager componente del DBMS responsabile di gestire i lock alle risorse del DB, e di rispondere alle richieste delle transazioni. AZIONI DEL LOCK MANAGER 1. Riceve una richiesta (r_lock, w_lock, unlock) da una transazione T, su un oggetto x (oggetto=tabella, colonna, etc). 2. Controlla la tabella stato/azione (slide precedente). 3. Se la risposta è OK, aggiorna lo stato della risorsa, e concede il controllo della risorsa alla transazione T. 4. Se la risposta è NO, inserisce la transazione T in una coda associata all’oggetto x.

Gestione delle Transazioni RISORSA x STATO(x): r_locked T 1: r_lock(x) LOCK MANAGER ACTIVE(x): {T {} 1} QUEUED(x): {} Answer to T 1: OK

Gestione delle Transazioni RISORSA x STATO(x): r_locked T 2: r_lock(x) LOCK MANAGER ACTIVE(x): {T {} 1, 1}T 2} QUEUED(x): {} Answer to T 2: OK

Gestione delle Transazioni RISORSA x STATO(x): r_locked T 3: w_lock(x) LOCK MANAGER ACTIVE(x): {T {} 1, 1}T 2} QUEUED(x): {T {} 3} Answer to T 3: NO

Gestione delle Transazioni Two Phase Lock (2 PL) Una transazione, dopo aver rilasciato un lock, non può acquisirne un altro. Ø In pratica, una transazione acquisisce prima tutti i lock delle risorse di cui necessita … Risorse Fase di Acquisizione Fase di Rilascio Time

Gestione delle Transazioni TRANSAZIONI T 1= r(x), w(y), Commit T 2= r(y), Commit T 1 T 2 r_lock(x) r(x) unlock(x) r_lock(y) r(y) SCHEDULE unlock(y) Commit Q. E’ uno schedule 2 PL? A. NO! w_lock(y) w(y) unlock(y) Commit

Gestione delle Transazioni TRANSAZIONI T 1= r(x), w(y), Commit T 2= r(y), Commit SCHEDULE T 1 T 2 r_lock(x) r(x) w_lock(y) r_lock(y) w(y) unlock(x) Q. E’ uno schedule 2 PL? A. SI! r(y) unlock(y) Commit

Gestione delle Transazioni Two Phase Lock (2 PL) Una transazione, dopo aver rilasciato un lock, non può acquisirne un altro. Ø Ogni schedule che rispetta il 2 PL e’ anche serializzabile (perchè ? ). Ø Ogni schedule che rispetta il 2 PL non può incorrere in configurazioni erronee dovute a: aggiornamento fantasma, lettura inconsistente, perdita di aggiornamento … che accade in caso di lettura sporca?

Gestione delle Transazioni TRANSAZIONI T 1= r(x), w(y), Commit T 2= r(y), Commit SCHEDULE T 1 T 2 r_lock(x) r(x) w_lock(y) r_lock(y) w(y) unlock(x) Lettura sporca! r(y) unlock(y) Abort Commit

Gestione delle Transazioni Strict Two Phase Lock (2 PL) I lock di una transazione sono rilasciati solo dopo aver effettuato le operazioni di commit/abort. Ø Variante strict del 2 PL, utilizzato in alcuni DBMS commerciali. Ø Uno schedule che rispetta lo S 2 PL eredita tutte le proprietà del 2 PL, ed inoltre NON presenta anomalie causate da problemi di lettura sporca.

Gestione delle Transazioni TRANSAZIONI T 1= r(x), w(y), Commit T 2= r(y), Commit SCHEDULE T 1 T 2 r_lock(x) r(x) w_lock(y) r_lock(y) w(y) Abort unlock(x) Q. E’ uno schedule S 2 PL? A. SI! unlock(y) r(y) Commit unlock(y)

Gestione delle Transazioni PROBLEMA: I protocolli 2 PL e S 2 PL possono generare schedule con situazioni di deadlock. TRANSAZIONI T 1= r(x), w(y), Commit T 2= r(y), w(x), Commit T 1 T 2 r_lock(x) r_lock(y) r(x) r(y) SCHEDULE w_lock(y) w_lock(x)

Gestione delle Transazioni Per gestire le situazioni di deadlock causate dal Lock Manager, si possono usare tecniche: 1. Uso dei timeout ogni operazione di una transazione ha un timeout entro il quale deve essere completata, pena annullamento (abort) della transazione stessa. T 1: r_lock(x, 4000), r(x), w_lock(y, 2000), w(y), commit, unlock(x), unlock(y)

Gestione delle Transazioni Per gestire le situazioni di deadlock causate dal Lock Manager, si possono usare tecniche: 2. Deadlock avoidance prevenire le configurazioni che potrebbero portare ad un deadlock … COME? ² Lock/Unlock di tutte le risorse allo stesso tempo. ² Utilizzo di time-stamp o di classi di priorità transazioni (problema: puo’ determinare starvation!)

Gestione delle Transazioni Per gestire le situazioni di deadlock causate dal Lock Manager, si possono usare tecniche: 3. Deadlock detection utilizzare algoritmi per identificare eventuali situazioni di deadlock, e prevedere meccanismi di recovery dal deadlock ² Grafo delle richieste/risorse utilizzato per identificare la presenza di cicli (corrispondenti a deadlock) ² In caso di ciclo, si fa abort delle transazioni coinvolte nel ciclo in modo da eliminare la mutua dipendenza …

Gestione delle Transazioni Un metodo alternativo al 2 PL per la gestione della concorrenza in un DBMS prevede l’utilizzo dei timestamp delle transazioni (metodo TS). Ø Ad ogni transazione si associa un timestamp che rappresenta il momento di inizio della transazione. Ø Ogni transazione non può leggere o scrivere un dato scritto da una transazione con timestamp maggiore. Ø Ogni transazione non può scrivere su un dato gia’ letto da una transazione con timestamp

Gestione delle Transazioni Un metodo alternativo al 2 PL per la gestione della concorrenza in un DBMS prevede l’utilizzo dei timestamp delle transazioni (metodo TS). Ø Ad ogni oggetto x si associano due indicatori: ² WTM(x) timestamp della transazione che ha fatto l’ultima scrittura su x. ² RTM(x) timestamp dell’ultima transazione (ultima=con t piu’ alto) che ha letto x.

Gestione delle Transazioni Lo scheduler di sistema verifica se un’eventuale azione (rt(x) o wt(x)) eseguita da una transazione T con timestamp t puo’ essere eseguita o meno: ² rt(x) Se t<WTM(x) allora la transazione viene uccisa. Se t>=WTM(x), la richiesta viene eseguita, ed RTM(x) viene aggiornato al massimo tra il valore precedente di RTM(x) e t stesso.

Gestione delle Transazioni Lo scheduler di sistema verifica se un’eventuale azione (rt(x) o wt(x)) eseguita da una transazione T con timestamp t puo’ essere eseguita o meno: ² wt(x) Se t<WTM(x) oppure t<RTM(x) allora la transazione viene uccisa. Altrimenti, la richiesta viene accettata, e WTM(x) viene posto uguale a t.

Gestione delle Transazioni ESEMPIO: RTM(x)=6, WTM(x)=3 T 5: r 5(x) OK, RTM(x)=6 T 9: w 9(x) OK, WTM(x)=9 T 6: w 6(x) NO, T 6 uccisa T 8: r 8(x) NO, T 8 uccisa T 10: r 10(x) OK, RTM(x)=10

Gestione delle Transazioni In SQL-3, ed in molti DBMS commerciali (DB 2, My. SQL, Postgre. SQL, Oracle, etc) sono definiti quattro livelli di isolamento transazioni: Livello Descrizione read uncommitted (read only) La transazione non emette lock in lettura, e non rispetta lock esclusivi da altre transazioni. read committed Richiede lock condivisi per effettuare le letture. repeteable read Applica il protocollo S 2 PL anche in lettura. serializable Applica il protocollo S 2 PL con lock di predicato. Ø S 2 PL utilizzato per le operazioni di scrittura, da tutti i livelli.

Gestione delle Transazioni SINTASSI My. SQL Ø Iniziare una transazione e completarla: START TRANSACTION … (Statements SQL) COMMIT/ROLLBACK Ø Configurare livello di isolamento di esecuzione: SET TRANSACTION ISOLATION LEVEL REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED | SERIALIZABLE

Gestione delle Transazioni SINTASSI My. SQL Ø Le transazioni sono utilizzabili solo su tabelle di tipo Inno. DB (ACID-compliant). Ø E’ possibile gestire manualmente le operazioni di lock su tabelle (non consigliabile su tabelle di tipo Inno. DB): LOCK TABLES tabella { READ | WRITE }

Gestione delle Transazioni Gestione delle transazioni Gestione della concorrenza Gestione dell’affidabilita’ DB Gestore dell’affidabilità garantisce atomicita’ e persistenza … COME? Usando log e checkpoint. Gestore della concorrenza garantisce l’isolamento in caso d esecuzione concorrente di piu’ transazioni.

Gestione delle Transazioni Gestore del’affidabilità verifica che siano garantite le proprietà di atomicità e persistenza delle transazioni. Ø Responsabile di implementare i comandi di: start transaction, commit, rollback Ø Responsabile di ripristinare il sistema dopo malfunzionamenti software (ripresa a caldo) Ø Responsabile di ripristinare il sistema dopo malfunzionamenti hardware (ripresa a freddo)

Gestione delle Transazioni Il controllore di affidabilità utilizza un log, nel quale sono indicate tutte le operazioni svolte dal DBMS. LOG, struttura fisica <10: 34, 11/12/2012, Transaction: T 1, INSERT(3, Mario, Rossi) INTO IMPIEGATI> <10: 35, 11/12/2012, Transaction: T 2, DELETE(3, Mario, Rossi) INTO IMPIEGATI> <10: 36, 11/12/2012, Transaction: T 3, INSERT(6, Maria, Bianchi) INTO IMPIEGATI>

Gestione delle Transazioni Il controllore di affidabilità utilizza un log, nel quale sono indicate tutte le operazioni svolte dal DBMS. LOG, struttura logica 10: 34 T 1, INSERT 10: 35 10: 36 T 2, DELETE T 3, INSERT Time Tramite il log, è possibile fare do/undo delle transazioni …

Gestione delle Transazioni Tramite il log, è possibile ripristinare lo stato completo del DBMS in caso di malfunzionamenti/guasti … a patto che non siano persi anche i dati del log! Ø Si assume che i dati del log siano memorizzati su memoria stabile (astrazione!). Ø Si possono usare opportune tecnologie per aumentare l’affidabilità RAID (Redundant Array of Independent Disks)

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time Due tipi di record: Record di transizione tengono traccia delle operazioni svolte da ciascuna transizione sul DBMS.

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time Due tipi di record: Record di transizione tengono traccia delle operazioni svolte da ciascuna transizione sul DBMS.

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time 1. Record di begin, commit, abort: tengono traccia del tipo di operazione e del nome (univoco) della transazione. B(T), C(T), B(T 2), C(T 2), B(T 3), A(T 3), etc

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time 2. Record di update: tengono traccia del nome (univoco) della transazione, dell’oggetto modificato (O), dello stato precedente (BS) e dello stato attuale (AS). U(T, O, BS, AS) -> U(T 1, ”CONTO”, 4, 5)

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time 3. Record di insert: tengono traccia del nome (univoco) della transazione, dell’oggetto modificato (O), dello stato attuale (AS). I(T, O, AS) -> I(T 1, ”CONTO”, 1000)

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time 4. Record di delete: tengono traccia del nome (univoco) della transazione, dell’oggetto modificato (O), dello stato precedente (BS). D(T, O, BS) -> D(T 1, ”CONTO”, 1000)

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time Ricapitolando, i record delle transazioni sono del tipo: Ø Ø B(T), C(T), A(T) U(T, O, BS, AS), I(T, O, AS) D(T, O, BS)

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time Due tipi di record: Record di transizione tengono traccia delle operazioni svolte da ciascuna transizione sul DBMS.

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time 1. Record di dump: tengono traccia degli eventi di backup completo della base di dati su memoria stabile. Tali eventi sono effettuati con una certa periodicità definita dall’amministratore del sistema. DUMP(DB)

Gestione delle Transazioni Il log si presenta come un file sequenziale suddiviso in record: Time 2. Record di checkpoint: tengono traccia delle transazioni attive presenti nel sistema. Transazione attiva transazione che non si è ancora conclusa con un’azione di commit o rollback. CK(T 1, T 2, T 3 …, Tn)

Gestione delle Transazioni Per aumentare l’efficienza prestazionale, tutti i DBMS utilizzano un buffer temporaneo di informazioni in memoria principale, il quale viene periodicamente scritto su memoria secondaria. Gestore del buffer (modulo del DBMS) HD RS del Buffer DBMS RAM DBMS

Gestione delle Transazioni Quando si effettua un checkpoint: 1. Si sospendono tutte le operazioni in corso sul DBMS. 2. Si rendono effettive anche su memoria secondaria tutte le operazioni effettuate da transazioni che hanno fatto commit, i cui dati si trovino ancora nel buffer (flush). 3. Si scrivono nel record di checkpoint del log tutte le transazioni attive del sistema. 4. Si riprende l’esecuzione delle operazioni.

Gestione delle Transazioni REGOLE di SCRITTURA del LOG ² Regola Write Ahead Log la parte BS (before state) di ogni record di log deve essere scritta prima che la corrispondente operazione venga effettuata nella base di bati. In pratica: I record di log devono essere scritti prima delle corrispondenti operazioni sulla base di dati, in modo da poter fare undo delle operazioni!

Gestione delle Transazioni REGOLE di SCRITTURA del LOG ² Regola di Commit Precedence la parte AS (after state) di ogni record di log deve essere scritta nel log prima di effettuare il commit della transazione. In pratica: I record di log devono essere scritti prima di effettuare l’operazione di commit, in modo da poter garantire il redo di una transazione non ancora scritta su memoria secondaria.

Gestione delle Transazioni ESEMPI di SCHEDULING di OPERAZIONI B(T) I(T, X, AS) I(T, Y, AS) C(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(X) w(Y) Ø Regola Write Ahead Log OK Ø Regola Commit Precedence OK

Gestione delle Transazioni ESEMPI di SCHEDULING di OPERAZIONI B(T) I(T, X, AS) I(T, Y, AS) C(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(X) w(Y) Ø Regola Write Ahead Log NO! Ø Regola Commit Precedence OK

Gestione delle Transazioni ESEMPI di SCHEDULING di OPERAZIONI B(T) I(T, X, AS) I(T, Y, AS) C(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(X) w(Y) Ø Regola Write Ahead Log OK Ø Regola Commit Precedence OK

Gestione delle Transazioni ESEMPI di SCHEDULING di OPERAZIONI B(T) I(T, X, AS) I(T, Y, AS) C(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(X) w(Y) Ø Nella pratica: le scritture sulla base di dati possono avvenire in qualsiasi momento a patto di garantire le due regole sui log. .

Gestione delle Transazioni I guasti possono essere dovuti a: Ø Malfunzionamenti software perdita del contenuto della memoria principale, nessun danno per la memoria secondaria. Ø Malfunzionamenti hardware (1) perdita di dati nella memoria secondaria, ma non nella memoria stabile. Ø Malfunzionamenti hardware (2) perdita di dati nella memoria secondaria e stabile.

Gestione delle Transazioni Ø Modello di funzionamento (fail-stop) Il DBMS usa tre stati: Fail Stop Normal Fail Boot Restart completato Restart Ø Normal esecuzione normale Ø Stop occorrenza di un guasto Ø Restart ripristino dai guasti

Gestione delle Transazioni Ø Modello di funzionamento (fail-stop) Due tipi di operazioni di ripristino: Fail Stop Normal Fail Boot Restart completato Restart Ø Ripresa a caldo Malfunziomenti software. Ø Ripresa a freddo Malfunzionamenti hardware (1).

Gestione delle Transazioni Ø La ripresa a caldo si articola in 4 fasi: 1. Si accede al log, lo si scorre fino all’ultimo record di checkpoint. B(T 1) B(T 2) U(T 2, O 1, B 1, A 1), I(T 1, O 2, A 2), B(T 3), C(T 1), B(T 4), U(T 3, O 2, B 3, A 3), U(T 3, O 3, B 4, A 4) CK(T 2, T 3, T 4) C(T 4) B(T 5) U(T 3, O 3, B 5, A 5) U(T 5, O 4, B 6, A 6) D(T 3, O 5, B 7), A(T 3), C(T 5), I(T 2, O 6, A 8)

Gestione delle Transazioni 2. Si decidono le transazioni da annullare (undo) o da rifare (redo). a. Si costruiscono due insiemi: UNDO e REDO. b. UNDO è inizializzato con la lista delle transazioni attive, REDO e’ vuoto. c. Si aggiungono ad UNDO tutte le transazioni T di cui esiste un record B(T). d. Si spostano da UNDO a REDO tutte le transazioni di cui esiste un record C(T).

Gestione delle Transazioni 3. Per il set di UNDO si ripercorre il file di log, disfacendo tutte le azioni effettuate da ogni transazione T contenuta nel set, dalla più recente alla meno recente. 4. Per il set di REDO si applicano le azioni affettuate da ogni transazione T contenuta nel set, dalla meno recente alla piu’ recente.

Gestione delle Transazioni B(T 1) B(T 2) U(T 2, O 1, B 1, A 1), I(T 1, O 2, A 2), B(T 3), C(T 1), B(T 4), U(T 3, O 2, B 3, A 3), U(T 4, O 3, B 4, A 4) CK(T 2, T 3, T 4) C(T 4) B(T 5) U(T 3, O 3, B 5, A 5) U(T 5, O 4, B 6, A 6) D(T 3, O 5, B 7), A(T 3), C(T 5), I(T 2, O 6, A 8) 1. Transazioni attive all’ultimo CK: {T 2, T 3, T 4}. 2. Costruzione degli insiemi UNDO/REDO UNDO={T 2, T 3, T 4}, REDO={} C(T 4) UNDO={T 2, T 3} REDO={T 4} B(T 5) UNDO={T 2, T 3, T 5} REDO={T 4} C(T 5) UNDO={T 2, T 3} REDO={T 4, T 5}

Gestione delle Transazioni B(T 1) B(T 2) U(T 2, O 1, B 1, A 1), I(T 1, O 2, A 2), B(T 3), C(T 1), B(T 4), U(T 3, O 2, B 3, A 3), U(T 4, O 3, B 4, A 4) CK(T 2, T 3, T 4) C(T 4) B(T 5) U(T 3, O 3, B 5, A 5) U(T 5, O 4, B 6, A 6) D(T 3, O 5, B 7), A(T 3), C(T 5), I(T 2, O 6, A 8) 3. UNDO delle transazioni {T 2, T 3}: I(T 2, O 6, A 8) DELETE O 6 D(T 3, O 5, B 7) INSERT (O 5=B 7) U(T 3, O 3, B 5, A 5) O 3=B 5 U(T 3, O 2, B 3, A 3) O 2=B 3 U(T 2, O 1, B 1, A 1) O 1=B 1

Gestione delle Transazioni B(T 1) B(T 2) U(T 2, O 1, B 1, A 1), I(T 1, O 2, A 2), B(T 3), C(T 1), B(T 4), U(T 3, O 2, B 3, A 3), U(T 4, O 3, B 4, A 4) CK(T 2, T 3, T 4) C(T 4) B(T 5) U(T 3, O 3, B 5, A 5) U(T 5, O 4, B 6, A 6) D(T 3, O 5, B 7), A(T 3), C(T 5), I(T 2, O 6, A 8) 4. REDO delle transazioni {T 4, T 5}: U(T 4, O 3, B 4, A 4) U(T 5, O 4, B 6, A 6) O 3=A 4 O 4=B 6

Gestione delle Transazioni Ø La ripresa a freddo si articola in 4 fasi: 1. Si copia il dump nel DB attuale (cercando di sovrascrivere solo la parte deteriorata). 2. Relativamente alla parte deteriorata, si scorre il log dal dump in poi fino all’ultimo checkpoint, e si effettuano tutte le azioni della transazioni concluse con un commit. 3. Si effettua la ripresa a caldo (con l’algoritmo visto prima).