Gestione delle Transazioni

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

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 T

,T

, T

di cui

ciascuna formata da un certo insieme di operazioni di scrittura (w

) e lettura (r

):

Es. T

=r

(x) r

(y) r

(z) w

(y) …

Si definisce schedule la sequenza di operazioni di lettura/scrittura di tutte le transazioni così come eseguite sulla base di dati:

r

(x) r

(y) r

(y) w

(y) w

(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

, T

, … T

}

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 Work T2= 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 Schedule

Serializzabili

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):

lock

(x) r(x) unlock(x)

lock

(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

A ZI ON E

Gestione delle Transazioni

RISORSA x

LOCK

MANAGER

T

: r_lock(x)

Answer to T₁: OK ACTIVE(x): {}

QUEUED(x): {}

STATO(x): r_locked ACTIVE(x): {T₁}

Gestione delle Transazioni

RISORSA x

LOCK

MANAGER

T

: r_lock(x)

Answer to T₂: OK ACTIVE(x): {}

QUEUED(x): {}

STATO(x): r_locked ACTIVE(x): {T₁} ACTIVE(x): {T_1,T₂}

Gestione delle Transazioni

RISORSA x

LOCK

MANAGER

T

: w_lock(x)

Answer to T₃: NO ACTIVE(x): {}

QUEUED(x): {}

STATO(x): r_locked ACTIVE(x): {T₁} ACTIVE(x): {T_1,T₂} QUEUED(x): {T₃}

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

Gestione delle Transazioni

T

= r(x), w(y), Commit T

= w(x), Commit

T₁ T₂

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

A. NO!

Gestione delle Transazioni

T

= r(x), w(y), Commit T

= r(y), Commit

T₁ T₂

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

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

T

= r(x), w(y), Abort T

= r(y), Commit

T₁ T₂

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

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

T

= r(x), w(y), Abort T

= r(y), Commit

T₁ T₂

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

A. SI!

PROBLEMA: I protocolli 2PL e S2PL possono generare schedule con situazioni di deadlock.

Gestione delle Transazioni

T

= r(x), w(y), Commit T

= r(y), w(x), Commit

TRANSAZIONI

SCHEDULE

T₁ T₂

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.

T

: 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 (r

(x) o w

(x)) eseguita da una transazione T con timestamp t puo’ essere eseguita o meno:

²  r

(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 (r

(x) o w

(x)) eseguita da una transazione T con timestamp t puo’ essere eseguita o meno:

²  w

(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

T

: r

(x) à OK , RTM(x)=6 T

: w

(x) à OK , WTM(x)=9 T

: w

(x) à NO , T

uccisa

T

: r

(x) à NO , T

uccisa

T

: r

(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 }

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.

<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 .

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.

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)

Ø  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)

Ø  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)

Ø  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)

Ø  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).

Gestione delle Transazioni