basi di dati e sistemi informativi struttura di un dbms: gestione delle transazioni home page del...

Basi di Dati e Sistemi

Informativi

Struttura di un DBMS:Gestione delle Transazioni

Home page del corso:

http://www.cs.unibo.it/~difelice/dbsi/

Gestione delle Transazioni

Transazione sequenza di operazioni SQL la cui esecuzione deve avvenire garantendo alcune caratteristiche di correttezza, isolamento e robustezza. Una transazione termina con commit (

“procedi”) o con abort ( “annulla”). Definite dall’utente, tramite comandi

SQL: start transaction … end transaction. Definite automaticamente dal sistema.

Atomicita’ 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 integrita’ 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 non deve essere perso.

PROPRIETA’ ACIDE DELLE TRANSAZIONI


Gestore della consistenza tipicamente implementata dai compilatori del DDL.

Prima di eseguire un’istruzione SQL, il suo effetto viene simulato.

Si verifica che tutti i vincoli di integrita’ siano rispettati, in caso contrario si genera un errore e si blocca l’esecuzione dell’istruzione corrente.


Memoria secondaria

Gestore della memoria secondaria

Gestore del buffer

Gestore deimetodi d’accesso

Gestore di Interrogazioni e aggiornamenti

Gestore delle transazioni

Gestore della concorrenza

Gestore dellaaffidabilità

Gestore delle affidabilita’ garantisce atomicita’ e persistenza delle transazioni.

Gestore della concorrenza garantisce l’isolamento delle transazioni.


Memoria secondaria


Gestore del buffer







Gestore della concorrenza garantiscel’isolamento delle transazioni.


Gestore del’affidabilita’ verifica che siano garantite le proprieta’ di atomicita’ 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)


Il controllore di affidabilita’ 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>


Il controllore di affidabilita’ 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, e’ possibile fare do/undo delle transazioni …


Tramite il log, e’ 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’affidabilita’ RAID (Redundant Array of Independent Disks)


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



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



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)



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)



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)



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)



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



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 periodicita’ definita dall’amministratore del sistema.

DUMP(DB)



Time

2. Record di checkpoint: tengono traccia delle transazioni attive presenti nel sistema. Transazione attiva transazione che non si e’ ancora conclusa con un’azione di commit o rollback.

CK(T1,T2,T3 …, Tn)


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


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.


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


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


ESEMPI di SCHEDULING di OPERAZIONI

Time

B(T) C(T)I(T,X,AS) I(T,Y,AS)

w(X) w(Y)

SCRITTURESUL DB

SCRITTURESUL LOG

Regola Write Ahead Log OK Regola Commit Precedence OK



Time


w(X) w(Y)

SCRITTURESUL DB

SCRITTURESUL LOG

Regola Write Ahead Log NO! Regola Commit Precedence OK



Time


w(X) w(Y)

SCRITTURESUL DB

SCRITTURESUL LOG

Regola Write Ahead Log OK Regola Commit Precedence OK



Time


w(X) w(Y)

SCRITTURESUL DB

SCRITTURESUL LOG

Nella pratica: le scritture sulla base di dati possono avvenire in qualsiasi momento a patto di garantire le due regole sui log ..


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.


Modello di funzionamento (fail-stop)

Fail

FailStop

Boot

Restart

Normal

Restartcompletato

Il DBMS usa tre stati: Normal

esecuzione normale

Stop occorrenza di un guasto

Restart ripristino dai guasti


Modello di funzionamento (fail-stop)

Fail

FailStop

Boot

Restart

Normal

Restartcompletato

Due tipi di operazioni di ripristino: Ripresa a caldo

Malfunziomenti software.

Ripresa a freddo Malfunzionamenti hardware (1).


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)


2. Si decidono le transazioni da annullare (undo) o da rifare (redo).

a. Si costruiscono due insiemi: UNDO e REDO.

b. UNDO e’ 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).


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



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}



3. UNDO delle transazioni {T2,T3}:

I(T2,O6,A8) DELETE O6D(T3,O5,B7) INSERT (O5=B7)U(T3,O3,B5,A5) O3=B5U(T3,O2,B3,A3) O2=B3U(T2,O1,B1,A1) O1=B1


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=A4U(T5,O4,B6,A6) O4=B6


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


Memoria secondaria


Gestore del buffer







Gestore della concorrenza garantisce l’isolamento delle transazioni.


T1= Read(x); x=x+1; Write(x); Commit WorkT2= Read(x); x=x+1; Write(x); Commit Work

In un DMBS, le transazioni vengono eseguite in concorrenza per ragioni di efficienza / scalabilita’ …Tuttavia, l’esecuzione concorrente determina un insieme di problematiche che devono essere gestite …

Se x=3, al termine delle transazioni x vale 5 (esecuzione sequenziale) … ma in esecuzione concorrente?


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


Problema2: Lettura sporca


Read(x)

x=x+1

Write(x)

Read(x)

Commit work

Rollback work

T2 legge 4!


Problema3: Letture inconsistenti


Read(x)

Read(x)

x=x+1

Write(x)

Commit work

Read(x)Commit work

T1 legge 3!

T1 legge 4!


Problema4: Aggiornamento Fantasma


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+zdeveessere =a 1000

Vincoloviolato!!


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 cosi’ come eseguite sulla base di dati:

r1(x) r2(y) r1(y) w4(y) w2(z) …


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)


Uno schedule S si dice serializzabile se produce lo stesso risultato di un qualunque scheduler seriale S’ delle stesse transazioni.


ScheduleSeriali

Schedule

ScheduleSerializzabili

CLASSI

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), e’ necessario aver precedentemente acquisito il controllo (lock) sulla risorsa stessa.

Lock in lettura (accesso condiviso) Lock in scrittura (mutua esclusione)


Su ogni lock possono essere definite due operazioni:

Richiesta del lock in lettura/scrittura. Rilascio del lock (unlock) acquisito in

precedenza.


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

AZ

ION

E

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’oggettoQueued(x) lista transazioni bloccate sull’oggetto


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 precedente).3. Se la risposta e’ OK, aggiorna lo stato della

risorsa, e concede il controllo della risorsa alla transazione T.

4. Se la risposta e’ NO, inserisce la transazione T in una coda associata all’oggetto x.


AZIONI DEL LOCK MANAGER


RISORSA x

LOCKMANAGER

T1: r_lock(x)

STATO(x): free

Answer to T1: OK

ACTIVE(x): {}

QUEUED(x): {}

STATO(x): r_locked

ACTIVE(x): {T1}


RISORSA x

LOCKMANAGER

T2: r_lock(x)

STATO(x): free

Answer to T2: OK

ACTIVE(x): {}

QUEUED(x): {}

STATO(x): r_locked

ACTIVE(x): {T1}ACTIVE(x): {T1,T2}


RISORSA x

LOCKMANAGER

T3: w_lock(x)

STATO(x): free

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 puo’ acquisirne un altro.


In pratica, una transazione acquisisce prima tutti i lock delle risorse cui necessita …

Time

Ris

ors

e

Fase di Acquisizione

Fase di Rilascio


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

T1 T2

r_lock(x)

r(x)

unlock(x)

r_lock(y)

r(y)

unlock(y)

Commit

w_lock(y)

w(y)

unlock(y)

Commit

TRANSAZIONI

SCHEDULE

Q. E’ uno schedule 2PL?

A. NO!



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 puo’ acquisirne un altro.


Ogni schedule che rispetta il 2PL e’ anche serializzabile (perche’ ?).

Ogni schedule che rispetta il 2PL non puo’ incorrere in configurazioni erronee dovute a: aggiornamento fantasma, lettura inconsistente, perdita di aggiornamento … che accade in caso di lettura sporca?



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.


Variante strict del 2PL, utilizzato in alcuni DBMS commerciali.

Uno schedule che rispetta lo S2PL eredita tutte le proprieta’ del 2PL, ed inoltre NON presenta anomalie causate da problemi di lettura sporca.



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.


T1= r(x), w(y), CommitT2= 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)



2. Deadlock avoidance prevenire le configurazioni che potrebbero portare ad un dealock … COME?

Lock/Unlock di tutte le risorse allo stesso tempo.

Utilizzo di time-stamp o di classi di priorita’ tra transazioni (problema: puo’ determinare starvation!)



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 …


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 puo’ leggere o scrivere un dato scritto da una transazione con timestamp maggiore.

Ogni transazione non puo’ scrivere su un dato gia’ letto da una transazione con timestamp maggiore.


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.


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.


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.


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

Versione multivalore dell’algoritmo TS-based per ogni oggetto x, si mantengono N copie (xt), a diversi timestamp t.

Ad ogni oggetto x corrispondono:

Un RTM(x) globale, per tutte le versioni.

Un array WTM(x)N, aggiornato ogni volta che una transazione scrive sull’oggetto x, all’istante N.


Versione multivalore dell’algoritmo TS-based per ogni oggetto x, si mantengono N copie (xt), a diversi timestamp t.

rt(x) sempre consentita. Se t> WTMN(x), allora si legge xN. Altrimenti, si legge xi, con:

WTMi(x)<t<WTMi+1(x)

wt(x) se t<RTM(x), si rifiuta la richiesta. Altrimenti si aggiunge una nuova copia xt e si aggiorna: WTMN(x)=t.


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

serializable Applica il protocollo S2PL con lock di predicato. S2PL utilizzato per le operazioni di scrittura, da tutti i livelli.

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

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

LOCK TABLEStabella { READ | WRITE }

basi di dati e sistemi informativi struttura di un dbms: gestione delle transazioni home page del...

Documents