Corso di Basi di Dati
Gestione delle Transazioni
Home page del corso:
http://www.cs.unibo.it/~difelice/dbsi/
SET NumItem=(SELECT COUNT(*) FROM ITEM WHERE (Codice=CodiceScelto));
IF (NumItem > 0) THEN
UPDATE ITEM SET Quantita=Quantita-1 WHERE (Codice=CodiceScelto));
INSERT INTO ORDINE(Data,Ordinante,ItemOrdinato) VALUES (NOW(), NomeOrdinante, CodiceScelto);
END IF;
Esempio. Gestione ordini su un sito di ecommerce.
Gestione delle Transazioni
ITEM(Codice,Descrizione,Prezzo,Quantita) ORDINE(Id, Data, Ordinante, ItemOrdinato)
(struttura del DB semplificata)
SET NumItem=(SELECT COUNT(*) FROM ITEM WHERE (Codice=CodiceScelto));
IF (NumItem > 0) THEN
UPDATE ITEM SET Quantita=Quantita-1 WHERE (Codice=CodiceScelto));
INSERT INTO ORDINE(Data,Ordinante,ItemOrdinato) VALUES (NOW(), NomeOrdinante, CodiceScelto);
END IF;
Esempio. Gestione ordini su un sito di ecommerce.
Gestione delle Transazioni
ITEM(Codice,Descrizione,Prezzo,Quantita) ORDINE(Id, Data, Ordinante, ItemOrdinato)
(struttura del DB semplificata)
Il sistema va in crash in questo punto!
SET NumItem=(SELECT COUNT(*) FROM ITEM WHERE (Codice=CodiceScelto));
IF (NumItem > 0) THEN
UPDATE ITEM SET Quantita=Quantita-1 WHERE (Codice=CodiceScelto));
INSERT INTO ORDINE(Data,Ordinante,ItemOrdinato) VALUES (NOW(), NomeOrdinante, CodiceScelto);
END IF;
Esempio. Gestione ordini su un sito di ecommerce.
Gestione delle Transazioni
ITEM(Codice,Descrizione,Prezzo,Quantita) ORDINE(Id, Data, Ordinante, ItemOrdinato)
(struttura del DB semplificata)
Due ordini in contemporanea eseguono la query
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
Le transazioni rappresentano unità di lavoro
elementare (insiemi di istruzioni SQL) che modificano il contenuto di una base di dati.
Gestione delle
Transazioni
start transaction
update SalariImpiegati set conto=conto-10
where (CodiceImpiegato = 123) if conto >0 commit work;
else rollback work
Le transazioni rappresentano unità di lavoro
elementare (insiemi di istruzioni SQL) che modificano il contenuto di una base di dati.
Le transazioni sono
comprese tra una start
transaction ed una
commit/
rollback
Gestione 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.
PROPRIETA’ ACIDE DELLE TRANSAZIONI
Gestione delle
Transazioni
DB DB
Gestione delle transazioni Gestione della
concorrenza
Gestione dell’affidabilità
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
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
T1= Read(x); x=x+1; Write(x); Commit WorkT2= Read(x); x=x+1; Write(x); Commit Work
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 …
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 Write(x)
Commit work T1
scrive 4
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
Transazione1 (T1) Transazione2 (T2) Read(x)
Read(x) x=x+1 Write(x) Commit work Read(x)
Commit work T1
legge 3!
T1 legge
4!
Gestione delle
Transazioni
Problema 4: Aggiornamento Fantasma
Transazione1 (T1) Transazione2 (T2) Read(x)
Read(y) Read(y)
y=y-100 Read(z) z=z+100
Write(y), Write(z) Commit work
Read(z)
s=x+y+z; Commit work Vincolo:
x+y+z deve essere
= a 1000
Vincolo violato
!!
Gestione delle
Transazioni
Uno schedule S si dice serializzabile se
produce lo stesso risultato di un qualunque scheduler seriale S’ delle stesse
transazioni.
Gestione delle Transazioni
Schedule Seriali
Schedule Schedule
Serializzabili
CLASSI
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
Come implementare il controllo della concorrenza?
Su ogni lock possono essere definite due operazioni:
Richiesta del lock in lettura/scrittura.
Rilascio del lock (unlock) acquisito in precedenza.
Gestione delle Transazioni
Transazione #0 (T_0):
r(x) w(y)
Transazione #0 (T_0):
lockr(x) r(x)
unlock(x) lockw(y) w(y)
unlock(y)
CODICE UTENTE
CODICE con LOCK
Lock Manager componente del DBMS responsabile di gestire i lock alle risorse del DB, e di rispondere alle richieste delle
transazioni.
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
STRUTTURE DATI del LOCK MANAGER
Lock Manager componente del DBMS responsabile di gestire i lock alle risorse del DB, e di rispondere alle richieste delle
transazioni.
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 successiva). 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
AZIONI DEL LOCK MANAGER
Su ogni lock possono essere definite due operazioni:
Richiesta del lock in lettura/scrittura.
Rilascio del lock (unlock) acquisito in precedenza.
Gestione delle Transazioni
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
STATO DELLA RISORSA
AZIONE
Gestione delle Transazioni
RISORSA x
LOCK
MANAGER
T1: r_lock(x)
Answer to T1: OK ACTIVE(x):
{}
QUEUED(x): {}
STATO(x): r_locked ACTIVE(x):
{T1}
Gestione delle Transazioni
RISORSA x
LOCK
MANAGER
T2: r_lock(x)
Answer to T2: OK ACTIVE(x):
{}
QUEUED(x): {}
STATO(x): r_locked ACTIVE(x):
{T1}
ACTIVE(x):
{T1,T2}
Gestione delle Transazioni
RISORSA x
LOCK
MANAGER
T3: w_lock(x)
Answer to T3: NO ACTIVE(x):
{}
QUEUED(x): {}
STATO(x): r_locked ACTIVE(x):
{T1}
ACTIVE(x):
{T1,T2}
QUEUED(x):
{T3}
Two Phase Lock (2PL) Una
transazione, dopo aver rilasciato un lock, non può acquisirne un altro.
Gestione delle Transazioni
In pratica, una transazione acquisisce prima tutti i lock delle risorse di cui
necessita …
Time
Risorse
Fase di Acquisizione Fase di Rilascio
Gestione delle Transazioni
T1= r(x), w(y), Commit
T2= w(x), Commit
T1 T2
r_lock(x) r(x)
unlock(x)
w_lock(x) W(x)
Unlock(x) Commit w_lock(y)
w(y)
unlock(y) Commit TRANSAZIONI
SCHEDULE
Q. E’ uno schedule 2PL?
A. NO!
Gestione delle Transazioni
T1= r(x), w(y), Commit
T2= r(y), Commit
T1 T2
r_lock(x) r(x)
w_lock(y)
r_lock(y) w(y)
unlock(y) unlock(x)
r(y)
unlock(y) Commit
Commit TRANSAZIONI
SCHEDULE
Q. E’ uno schedule 2PL?
A. SI!
Two Phase Lock (2PL) Una
transazione, dopo aver rilasciato un lock, non può acquisirne un altro.
Gestione delle Transazioni
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
T1= r(x), w(y), Abort T2= r(y), Commit
T1 T2
r_lock(x) r(x)
w_lock(y)
r_lock(y) w(y)
unlock(y) unlock(x)
r(y)
unlock(y) Abort
Commit TRANSAZIONI
SCHEDULE
Lettura sporca!
Strict Two Phase Lock (2PL) I lock di una transazione sono rilasciati solo dopo aver effettuato le operazioni di
commit/abort.
Gestione delle Transazioni
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
T1= r(x), w(y), Abort T2= r(y), Commit
T1 T2
r_lock(x) r(x)
w_lock(y)
r_lock(y) w(y)
Abort
unlock(x) unlock(y)
r(y) Commit unlock(y) TRANSAZIONI
SCHEDULE
Q. E’ uno schedule S2PL?
A. SI!
PROBLEMA: I protocolli 2PL e S2PL possono generare schedule con situazioni di
deadlock.
Gestione delle Transazioni
T1= r(x), w(y), Commit
T2= r(y), w(x), Commit
TRANSAZIONI
SCHEDULE
T1 T2
r_lock(x)
r_lock(y) r(x)
r(y) w_lock(y)
w_lock(x)
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 time-stamp 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 già 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 time-stamp 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
Gestione delle Transazioni
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
In SQL-3, ed in molti DBMS commerciali (DB2, MySQL, PostgreSQL, Oracle, etc) sono definiti quattro livelli di isolamento tra transazioni:
Gestione delle 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.
MySQL offre quattro livelli di isolamento:
READ UNCOMMITTED sono visibili gli aggiornamenti non consolidati fatti da altri.
READ COMMITTED aggiornamenti visibili solo se consolidati (ossia solo dopo COMMIT).
REPEATABLE READ tutte le letture di un dato operate da una transazione leggono sempre lo stesso valore (comportamento di default).
SERIALIZABLE lettura di un dato blocca gli aggiornamenti fino al termine della transazione stessa che ha letto il dato (lock applicato ad ogni SELECT).
Gestione delle
Transazioni
SINTASSI MySQL
Gestione delle Transazioni
Iniziare una transazione e completarla:
SET AUTOCOMMIT =0;
START TRANSACTION
… (Statements SQL) COMMIT/ROLLBACK
Configurare livello di isolamento di esecuzione:
SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED | SERIALIZABLE
SINTASSI MySQL
Gestione delle Transazioni
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 }
DB DB
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
Gestore dell’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: 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.
LOG, struttura logica
Time
10:34 10:35 10:36
T1, INSERT T2, DELETE T3, INSERT
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.
Record di sistema tengono traccia delle operazioni di sistema (dump/checkpoint).
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.
Record di sistema tengono traccia delle operazioni di sistema (dump/checkpoint).
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.
Record di sistema tengono traccia delle operazioni di sistema (dump/checkpoint).
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
RS
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.
HD Buffer del
DBMS DBMS
Gestore del buffer (modulo del DBMS)
RAM
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
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!
REGOLE di SCRITTURA del LOG
Gestione delle
Transazioni
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.
REGOLE di SCRITTURA del LOG
Gestione delle
Transazioni
ESEMPI di SCHEDULING di OPERAZIONI
Time
B(T) I(T,X,AS) I(T,Y,AS) C(T)
w(X) w(Y)
SCRITTURE SUL DB
SCRITTURE SUL LOG
Regola Write Ahead Log OK
Regola Commit Precedence OK
Gestione delle
Transazioni
ESEMPI di SCHEDULING di OPERAZIONI
Time
B(T) I(T,X,AS) I(T,Y,AS) C(T)
w(X) w(Y)
SCRITTURE SUL DB
SCRITTURE SUL LOG
Regola Write Ahead Log NO!
Regola Commit Precedence OK
Gestione delle
Transazioni
ESEMPI di SCHEDULING di OPERAZIONI
Time
B(T) I(T,X,AS) I(T,Y,AS) C(T)
w(X) w(Y)
SCRITTURE SUL DB
SCRITTURE SUL LOG
Regola Write Ahead Log OK
Regola Commit Precedence OK
Gestione delle
Transazioni
ESEMPI di SCHEDULING di OPERAZIONI
Time
B(T) I(T,X,AS) I(T,Y,AS) C(T)
w(X) w(Y)
SCRITTURE SUL DB
SCRITTURE SUL LOG
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)
Fail Fail
Stop
Boot Restart
Normal
Restart completato
Il DBMS usa tre stati:
Normal esecuzione normale
Stop
occorrenza di un guasto
Restart ripristino dai guasti
Gestione delle
Transazioni
Modello di funzionamento (fail- stop)
Fail Fail
Stop
Boot Restart
Normal
Restart completato
Due tipi di
operazioni di ripristino:
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) O3=A4 U(T5,O4,B6,A6) 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).