La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Basi di Dati e Sistemi Informativi Struttura di un DBMS: Gestione delle Transazioni Home page del corso:

Presentazioni simili


Presentazione sul tema: "Basi di Dati e Sistemi Informativi Struttura di un DBMS: Gestione delle Transazioni Home page del corso:"— Transcript della presentazione:

1 Basi di Dati e Sistemi Informativi Struttura di un DBMS: Gestione delle Transazioni Home page del corso:

2 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 dallutente, tramite comandi SQL: start transaction … end transaction. Definite automaticamente dal sistema.

3 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 Lesecuzione di una transazione deve essere indipendente dalle altre. Persistenza Leffetto di una transazione che ha fatto commit non deve essere perso. Gestione delle Transazioni

4 Gestore della consistenza tipicamente implementata dai compilatori del DDL. Prima di eseguire unistruzione 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 lesecuzione dellistruzione corrente. Gestione delle Transazioni

5 Gestore della memoria secondaria Gestore del buffer Gestore dei metodi daccesso Gestore di Interrogazioni e aggiornamenti Gestore delle transazioni Gestore della concorrenza Gestore della affidabilità Gestore delle affidabilita garantisce atomicita e persistenza delle transazioni. Gestore della concorrenza garantisce lisolamento delle transazioni. Gestione delle Transazioni

6 Gestore della memoria secondaria Gestore del buffer Gestore dei metodi daccesso Gestore di Interrogazioni e aggiornamenti Gestore delle transazioni Gestore della concorrenza Gestore delle affidabilita garantisce atomicita e persistenza delle transazioni. Gestore della concorrenza garantiscelisolamento delle transazioni. Gestione delle Transazioni

7 Gestore delaffidabilita 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) Gestione delle Transazioni

8 Il controllore di affidabilita utilizza un log, nel quale sono indicate tutte le operazioni svolte dal DBMS. Gestione delle Transazioni

9 Il controllore di affidabilita utilizza un log, nel quale sono indicate tutte le operazioni svolte dal DBMS. Time 10:3410:35 10:36 T1, INSERTT2, DELETE T3, INSERT Tramite il log, e possibile fare do/undo delle transazioni … Gestione delle Transazioni

10 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 laffidabilita RAID ( Redundant Array of Independent Disks ) Gestione delle Transazioni

11 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

12 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

13 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

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

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

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

17 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

18 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

19 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 periodicita definita dallamministratore del sistema. DUMP(DB) Gestione delle Transazioni

20 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 e ancora conclusa con unazione di commit o rollback. CK(T1,T2,T3 …, Tn) Gestione delle Transazioni

21 RS Per aumentare lefficienza 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

22 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 lesecuzione delle operazioni. Gestione delle Transazioni

23 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

24 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 loperazione 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

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

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

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

28 ESEMPI di SCHEDULING di OPERAZIONI Time B(T) C(T) I(T,X,AS)I(T,Y,AS) 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

29 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

30 Modello di funzionamento ( fail-stop ) 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

31 Modello di funzionamento ( fail-stop ) 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

32 La ripresa a caldo si articola in 4 fasi: 1.Si accede al log, lo si scorre fino allultimo 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

33 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). Gestione delle Transazioni

34 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. Gestione delle Transazioni

35 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 allultimo 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

36 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

37 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

38 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 allultimo checkpoint, e si effettuano tutte le azioni della transazioni concluse con un commit. 3.Si effettua la ripresa a caldo (con lalgoritmo visto prima). Gestione delle Transazioni

39 Gestore della memoria secondaria Gestore del buffer Gestore dei metodi daccesso Gestore di Interrogazioni e aggiornamenti Gestore delle transazioni Gestore della affidabilità Gestore delle affidabilita garantisce atomicita e persistenza delle transazioni. Gestore della concorrenza garantisce lisolamento delle transazioni. Gestione delle Transazioni

40 T1= Read(x); x=x+1; Write(x); Commit Work T2= Read(x); x=x+1; Write(x); Commit Work In un DMBS, le transazioni vengono eseguite in concorrenza per ragioni di efficienza / scalabilita … Tuttavia, lesecuzione 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 ? Gestione delle Transazioni

41 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 Gestione delle Transazioni

42 Problema2 : 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

43 Problema3 : Letture inconsistenti Transazione1 (T1)Transazione2 (T2) Read(x) x=x+1 Write(x) Commit work Read(x) Commit work T1 legge 3! T1 legge 4! Gestione delle Transazioni

44 Problema4 : Aggiornamento Fantasma Transazione1 (T1)Transazione2 (T2) Read(x) 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

45 Date un insieme di transazioni T 1,T 2, T n, di cui ciascuna formata da un certo insieme di operazioni di scrittura ( w i ) e lettura ( r i ): 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 cosi come eseguite sulla base di dati: r 1 (x) r 2 (y) r 1 (y) w 4 (y) w 2 (z) … Gestione delle Transazioni

46 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, … T n } Schedule seriale ottenibile se: (i) Le transazioni sono eseguite uno alla volta (scenario non realistico) (ii) Le transazioni sono completamente indipendenti luna dallaltra (improbabile) Gestione delle Transazioni

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

48 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 ) Gestione delle Transazioni

49 Su ogni lock possono essere definite due operazioni : Richiesta del lock in lettura/scrittura. Rilascio del lock ( unlock ) acquisito in precedenza. Gestione delle Transazioni Liberor_lockedw_locked r_lock OK/r_locked NO/w_locked w_lock OK/w_lockedNO/r_lockedNO/w_locked unlock erroreOK/dipendeOK/libero STATO DELLA RISORSA AZIONE

50 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 delloggetto ( libero/r_locked/w_locked ) Active( x ) lista transazioni attive sulloggetto Queued( x ) lista transazioni bloccate sulloggetto Gestione delle Transazioni STRUTTURE DATI del LOCK MANAGER

51 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 alloggetto x. Gestione delle Transazioni AZIONI DEL LOCK MANAGER

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

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

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

55 Two Phase Lock (2PL) Una transazione, dopo aver rilasciato un lock, non puo acquisirne un altro. Gestione delle Transazioni In pratica, una transazione acquisisce prima tutti i lock delle risorse cui necessita … Time Risorse

56 Gestione delle Transazioni T 1 = r(x), w(y), Commit T 2 = r(y), Commit T1T1 T2T2 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

57 Gestione delle Transazioni T 1 = r(x), w(y), Commit T 2 = r(y), Commit T1T1 T2T2 r_lock(x) r(x) w_lock(y) r_lock(y) w(y) unlock(y) unlock(x) r(y) unlock(y) Commit TRANSAZIONI SCHEDULE

58 Two Phase Lock (2PL) Una transazione, dopo aver rilasciato un lock, non puo acquisirne un altro. Gestione delle Transazioni 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 ?

59 Gestione delle Transazioni T 1 = r(x), w(y), Commit T 2 = r(y), Commit T1T1 T2T2 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

60 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 proprieta del 2PL, ed inoltre NON presenta anomalie causate da problemi di lettura sporca.

61 Gestione delle Transazioni T 1 = r(x), w(y), Commit T 2 = r(y), Commit T1T1 T2T2 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

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

63 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 1 : r_lock(x,4000), r(x), w_lock(y,2000), w(y), commit, unlock(x), unlock(y) Gestione delle Transazioni

64 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 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 !) Gestione delle Transazioni

65 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

66 Un metodo alternativo al 2PL per la gestione della concorrenza in un DBMS prevede lutilizzo 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. Gestione delle Transazioni

67 Un metodo alternativo al 2PL per la gestione della concorrenza in un DBMS prevede lutilizzo dei time- stamp delle transazioni (metodo TS ). Ad ogni oggetto x si associano due indicatori : WTM ( x ) timestamp della transazione che ha fatto lultima scrittura su x. RTM ( x ) timestamp dellultima transazione (ultima=con t piu alto) che ha letto x. Gestione delle Transazioni

68 Lo scheduler di sistema verifica se uneventuale azione ( r t (x) o w t (x) ) eseguita da una transazione T con timestamp t puo essere eseguita o meno: r t (x) 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

69 Lo scheduler di sistema verifica se uneventuale azione ( r t (x) o w t (x) ) eseguita da una transazione T con timestamp t puo essere eseguita o meno: w t (x) Se t

70 ESEMPIO : RTM(x)=6, WTM(x)=3 Gestione delle Transazioni 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

71 Versione multivalore dellalgoritmo TS-based per ogni oggetto x, si mantengono N copie (x t ), 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 sulloggetto x, allistante N. Gestione delle Transazioni

72 Versione multivalore dellalgoritmo TS-based per ogni oggetto x, si mantengono N copie (x t ), a diversi timestamp t. r t (x) sempre consentita. Se t> WTM N (x), allora si legge x N. Altrimenti, si legge x i, con: WTM i (x)

73 In SQL-3, ed in molti DBMS commerciali (DB2, MySQL, PostgreSQL, Oracle, etc) sono definiti quattro livelli di isolamento tra transazioni: Gestione delle Transazioni LivelloDescrizione 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.

74 SINTASSI MySQL Gestione delle Transazioni 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

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


Scaricare ppt "Basi di Dati e Sistemi Informativi Struttura di un DBMS: Gestione delle Transazioni Home page del corso:"

Presentazioni simili


Annunci Google