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 SalariImpiegati
set conto=conto*1.2
where (CodiceImpiegato = 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 SalariImpiegati
set conto=conto-10
where (CodiceImpiegato = 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’
Gestore dell’affidabilità  garantisce atomicità e persistenza
… COME? Usando log e checkpoint.
Gestore della concorrenza  garantisce l’isolamento in caso di
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 che devono essere gestite …
T1= Read(x); x=x+1; Write(x); Commit Work
T2= 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
Transazione1 (T1)
Transazione2 (T2)
Read(x)
x=x+1
Read(x)
x=x+1
Write(x)
Commit work
T1
scrive 4
Write(x)
Commit work
T2
scrive 4
Gestione delle Transazioni
Problema 2: Lettura sporca
Transazione1 (T1)
Transazione2 (T2)
Read(x)
x=x+1
Write(x)
Read(x)
Commit work
Rollback work
T2
legge 4!
Gestione delle Transazioni
Problema 3: Letture inconsistenti
T1
legge 3!
Transazione1 (T1)
Transazione2 (T2)
Read(x)
Read(x)
x=x+1
Write(x)
Commit work
T1
legge 4!
Read(x)
Commit work
Gestione delle Transazioni
Problema 4: Aggiornamento Fantasma
Vincolo:
x+y+z
deve
essere =
a 1000
Transazione1 (T1)
Transazione2 (T2)
Read(x)
Read(y)
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 T1,T2, Tn, di cui
ciascuna formata da un certo insieme di operazioni di
scrittura (wi) e lettura (ri):
Es. T1=r1(x) r1(y) r1(z) w1(y) …
Si definisce schedule la sequenza di operazioni di
lettura/scrittura di tutte le transazioni così come
eseguite sulla base di dati:
r1(x) r2(y) r1(y) w4(y) w2(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={T1, T2, … 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.
Schedule
Serializzabili
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:
 Richiesta del lock in lettura/scrittura.
 Rilascio del lock (unlock) acquisito in precedenza.
AZIONE
STATO DELLA RISORSA
Libero
r_locked
w_locked
r_lock
OK/r_locked
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
T1: r_lock(x)
LOCK
MANAGER
ACTIVE(x): {T
{} 1}
QUEUED(x): {}
Answer to T1: OK
Gestione delle Transazioni
RISORSA x
STATO(x): r_locked
T2: r_lock(x)
LOCK
MANAGER
ACTIVE(x): {T
{} 1,
1}T2}
QUEUED(x): {}
Answer to T2: OK
Gestione delle Transazioni
RISORSA x
STATO(x): r_locked
T3: w_lock(x)
LOCK
MANAGER
ACTIVE(x): {T
{} 1,
1}T2}
QUEUED(x): {T
{} 3}
Answer to T3: NO
Gestione delle Transazioni
Two Phase Lock (2PL)  Una transazione, dopo
aver rilasciato un lock, non può acquisirne un altro.
Risorse
 In pratica, una transazione acquisisce prima tutti
i lock delle risorse di cui necessita …
Time
Gestione delle Transazioni
TRANSAZIONI
T1= r(x), w(y), Commit
T2= r(y), Commit
T1
T2
r_lock(x)
r(x)
unlock(x)
r_lock(y)
r(y)
SCHEDULE
unlock(y)
Commit
w_lock(y)
w(y)
A. NO!
unlock(y)
Commit
Gestione delle Transazioni
TRANSAZIONI
T1= r(x), w(y), Commit
T2= r(y), Commit
T1
T2
r_lock(x)
r(x)
w_lock(y)
r_lock(y)
SCHEDULE
w(y)
unlock(y)
unlock(x)
r(y)
unlock(y)
A. SI!
Commit
Commit
Gestione delle Transazioni
Two Phase Lock (2PL)  Una transazione, dopo
aver rilasciato un lock, non può acquisirne un altro.
 Ogni schedule che rispetta il 2PL e’ anche
serializzabile (perchè ?).
 Ogni schedule che rispetta il 2PL 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
T1= r(x), w(y), Commit
T2= r(y), Commit
T1
T2
r_lock(x)
r(x)
w_lock(y)
r_lock(y)
SCHEDULE
w(y)
unlock(y)
unlock(x)
r(y)
unlock(y)
Abort
Commit
Gestione delle Transazioni
Strict Two Phase Lock (2PL)  I lock di una
transazione sono rilasciati solo dopo aver effettuato
le operazioni di commit/abort.
 Variante strict del 2PL, utilizzato in alcuni
DBMS commerciali.
 Uno schedule che rispetta lo S2PL eredita tutte
le proprietà del 2PL, ed inoltre NON presenta
anomalie causate da problemi di lettura sporca.
Gestione delle Transazioni
TRANSAZIONI
T1= r(x), w(y), Commit
T2= r(y), Commit
T1
T2
r_lock(x)
r(x)
w_lock(y)
r_lock(y)
SCHEDULE
w(y)
Abort
unlock(x)
unlock(y)
r(y)
A. SI!
Commit
unlock(y)
Gestione delle Transazioni
PROBLEMA: I protocolli 2PL e S2PL possono
generare schedule con situazioni di deadlock.
TRANSAZIONI
T1= r(x), w(y), Commit
T2= r(y), w(x), Commit
T1
T2
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 tre 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.
T1: 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 tre 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à tra
transazioni (problema: puo’ determinare starvation!)
Gestione delle Transazioni
Per gestire le situazioni di deadlock causate dal Lock
Manager, si possono usare tre 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 2PL 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 maggiore.
Gestione delle Transazioni
Un metodo alternativo al 2PL 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
T5: r5(x)
 OK, RTM(x)=6
T9: w9(x)
 OK, WTM(x)=9
T6: w6(x)
 NO, T6 uccisa
T8: r8(x)
 NO, T8 uccisa
T10: r10(x)
 OK, RTM(x)=10
Gestione delle Transazioni
In SQL-3, ed in molti DBMS commerciali (DB2,
MySQL, PostgreSQL, Oracle, etc) sono definiti
quattro livelli di isolamento tra 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 S2PL anche in lettura.
serializable
Applica il protocollo S2PL con lock di predicato.
 S2PL utilizzato per le operazioni di scrittura, da tutti i livelli.
Gestione delle Transazioni
SINTASSI MySQL
 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 MySQL
 Le transazioni sono utilizzabili solo su tabelle di
tipo InnoDB (ACID-compliant).
 E’ possibile gestire manualmente le operazioni di
lock su tabelle (non consigliabile su tabelle di tipo
InnoDB):
LOCK TABLES
tabella { READ | WRITE }
Gestione delle Transazioni
Gestione delle transazioni
Gestione della concorrenza
Gestione dell’affidabilita’
Gestore dell’affidabilità  garantisce atomicita’ e persistenza
… COME? Usando log e checkpoint.
Gestore della concorrenza  garantisce l’isolamento in caso di
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.
<10:34, 11/12/2012, Transaction: T1, INSERT(3,Mario, Rossi)
INTO IMPIEGATI>
<10:35, 11/12/2012, Transaction: T2, DELETE(3,Mario, Rossi)
INTO IMPIEGATI>
<10:36, 11/12/2012, Transaction: T3, 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.
10:34
T1, INSERT
10:35
10:36
T2, DELETE
T3, 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(T2),C(T2),B(T3),A(T3), etc
Gestione delle Transazioni
Il log si presenta come un file sequenziale
suddiviso in record:
Time
2. Record di update: tengono traccia del del nome (univoco)
della transazione, dell’oggetto modificato (O), dello stato
precedente (BS) e dello stato attuale (AS).
U(T,O,BS,AS) -> U(T1,”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 del nome (univoco)
della transazione, dell’oggetto modificato (O), dello stato
attuale (AS).
I(T,O,AS) -> I(T1,”CONTO”,1000)
Gestione delle Transazioni
Il log si presenta come un file sequenziale
suddiviso in record:
Time
4. Record di delete: tengono traccia del del nome (univoco)
della transazione, dell’oggetto modificato (O), dello stato
precedente (BS).
D(T,O,BS) -> D(T1,”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(T1,T2,T3 …, 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)
RAM
RS
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)
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)
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)
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)
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(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3),
C(T1), B(T4), U(T3,O2, B3, A3), U(T3,O3, B4, A4)
CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5)
U(T5,O4,B6,A6) D(T3,O5,B7), A(T3), C(T5),
I(T2,O6,A8)
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(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3), C(T1),
B(T4), U(T3,O2, B3, A3), U(T4,O3, B4, A4)
CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6)
D(T3,O5,B7), A(T3), C(T5), I(T2,O6,A8)
1. Transazioni attive all’ultimo CK: {T2, T3, T4}.
2. Costruzione degli insiemi UNDO/REDO
UNDO={T2,T3,T4}, REDO={}
C(T4)  UNDO={T2,T3} REDO={T4}
B(T5)  UNDO={T2,T3,T5} REDO={T4}
C(T5)  UNDO={T2,T3} REDO={T4,T5}
Gestione delle Transazioni
B(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3), C(T1),
B(T4), U(T3,O2, B3, A3), U(T4,O3, B4, A4)
CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6)
D(T3,O5,B7), A(T3), C(T5), I(T2,O6,A8)
3. UNDO delle transazioni {T2,T3}:
I(T2,O6,A8) 
DELETE O6
D(T3,O5,B7) 
INSERT (O5=B7)
U(T3,O3,B5,A5)  O3=B5
U(T3,O2,B3,A3)  O2=B3
U(T2,O1,B1,A1)  O1=B1
Gestione delle Transazioni
B(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3), C(T1),
B(T4), U(T3,O2, B3, A3), U(T4,O3, B4,A4)
CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6)
D(T3,O5,B7), A(T3), C(T5), I(T2,O6,A8)
4. REDO delle transazioni {T4,T5}:
U(T4,O3,B4,A4) 
U(T5,O4,B6,A6) 
O3=A4
O4=B6
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).