Tecnologia di un Database Server

Tecnologia di un Database Server
Stefania Costantini, Panagiota Tsintza Dispensa per il Corso di Basi di dati 1

Database Server Un database server può essere definito come:
Un sistema dedicato alla gestione dei dati. Un componente che data un operazione su una DB controlla se è sintatticamente corretta, esegue gli accessi e trasferisce i dati. Meccanismo interno per realizzare le funzionalità di sistemi per la gestione dei dati (DBMS).

Funzionalità di DBMS Affidabilità: capacità del sistema di conservare intatto il contenuto delle DB in caso di malfunzionamenti (backup e recovery) Privatezza dei dati: tramite meccanismi di autorizzazione (per es. login) Efficienza: operazioni su DB utilizzando un numero raggionevole di risorse (tempo, spazio) Efficacia: dipende dall’ attivita di progettazione della DB

}SERVER Modello di un Sistema Transazione 1 Transazione N Bot
SQL Queries Commit, Abort Eot Ottimizzatore Query Esecutore Query Scheduler Buffer Manager Recovery manager }SERVER Database

Componenti di un server
Un server per la gestione dei dati consiste di: 1) Un ottimizzatore: decide le strategie di accesso ai dati in modo da rispondere alle operazioni (di solito interrogazioni) su una DB. L’ ottimizzatore prende in input una interrogazione ed esegue un parsing lessicale, sintattico e semantico. Se l’ interrogazione è corretta la trasforma in una forma interna (analoga all’algebra relazionale).

Componenti di un server (cont.)
Un server per la gestione dei dati consiste di: 2) Un gestore dei metodi di accesso ai dati (noto come RRS) che esegue gli accessi fisici ai dati, in accordo alla strategia definita dall’ottimizzatore. 3) Un buffer manager che esegue il trasferimento effettivo delle pagine di DB dai dispositivo di memoria di base (in remoto) alla memoria centrale. 4) Un controllore di affidabilità utilizzato per garantire il giusto funzionamento di un DB in caso di malfunzionamenti o guasti. Gestisce il ripristino del sistema durante i malfunzionamenti e guasti. 5) Un controllore di concorrenza che regola gli accessi concorrenti alla base di dati

Transazioni Una transazione identifica un’unità di lavoro elementare svolta da un’applicazione, cui si vogliono associare caratteristiche di robustezza,correttezza ed isolamento [sistemi transazionali]. Dal punto del vista del sistema: unita di esecuzione. Dal punto di vista dell’ utente: interazione con il sistema (richiesta e risposta). SINTASSI: bot (o begin transaction) corpo della transizione eof (o end transaction)

Transazioni Il corpo delle transazioni comprende le seguenti istruzioni: commit work (o commit): la transazione va a buon fine. rollback work (o abort): annulla gli effetti del lavoro svolto dalla transazione e quindi non ha alcun effetto sulla DB Esempio: begin transaction x = x*2; y = y+4; if y > x commit work else rollback work; end transaction

Transazioni Una transazione si dice ben formata se:
Sintatticamente e semanticamente corretta. Comincia con begin transaction (bot) Termina con end transaction (eot) Nel suo corso viene eseguito uno solo dei due comandi commit work o rollback work Dopo una istruzione work o rollback work non è consentito di effettuare ulteriori operazioni di accesso e/o modifica nella DB

Stati di una transazione

Transazioni Il codice di transazione gode delle cosiddette proprietà ACID che sta per l’ acronimo: Atomicity Consistency Isolation Durability Controllo affidabillità Compilatori DDL Controllo concorrenza

Le proprietà ACID: Atomicità
Una transazione è un “atomo” le istruzioni di una transazione sono indivisibili. Una transazione termina in due modi diversi: tutte le istruzioni vengono eseguite con successo producendo degli effetti nella DB. almeno una istruzione fallisce e la transazione non ha alcun effetto nella DB (continua)

Nel caso di una transazione riuscita (commit) il sistema deve essere in grado di rifare il lavoro svolto dalle transazioni tramite una operazione di REDO Nel caso di una transazione senza successo la transazione non ha alcun effetto nella DB, cosi il sistema deve essere in grado di ricostruire lo stato iniziale della DB tramite una operazione di UNDO prima di un commit un guasto provoca l’ eliminazione di tutti gli effetti apportati nella DB fino a quel momento, mentre appena si esegue l’ istruzione di rollback work la transazione viene sospesa

Le proprietà ACID: Consistenza
Le istruzioni di una transazione non devono violare i vincoli imposti sulla DB. Se uno dei vincoli viene violato il sistema interviene annullando la transazione o correggendo la violazione. Verifica dei vincoli In runtime: il sistema rimuove gli effetti della istruzione che ha provocato la violazione del vincolo (senza abort) Alla fine della transazione dopo il commit il quale non va a buon fine. L’ effetto è una operazione di UNDO

Le proprietà ACID: Isolamento
Transazione indipendente dalla contemporanea esecuzione di altre transazioni => il risultato dell’ esecuzione concorrente di un insieme di transazioni è analogo a quello ottenuto dalle stesse transazioni eseguite in seriale modo da impedire che una esecuzione di abort causi l’ esecuzione di un abort di altre esecuzioni Evita la reazione a catena (effetto dominio)

Le proprietà ACID: Persistenza
L’ effetto di una transazione riuscita (commit eseguito correttamente) viene memorrizzato in modo permanente nella DB Attenzione: Una transazione utente può incapsulare diverse transazioni di sistema. Una transazione di sistema può incapsulare diverse transazioni utente

Tecnologia di un data base server: Controllo della Concorrenza

Concorrenza: esempio Supponiamo che una transazione venga eseguita simultaneamente a due o più applicazioni (ad esempio due agenzie di viaggi) allo scopo di prenotare un posto sullo stesso volo È possibile una evoluzione temporale come la seguente: tempo A questo punto abbiamo una stessa prenotazione dello stesso posto. Motivo: assenza di isolamento Applicazione 1 Applicazione 2 Trova posto Prenota il posto

Controllo della Concorrenza
Motivo: richieste concorrenti provenienti da diversi utenti Una unità di misura spesso utilizzata per valutare le prestazioni di un DBMS è il numero di transazioni al secondo (tps). L’ordine di grandezza può variare da alcune centinaia ad alcune centinaia di migliaia. L’esecuzione seriale è impensabile. Il controllo di concorrenza riguarda le operazioni di ingresso/uscita sui blocchi (pagine): Read: da memoria di massa a quella centrale. Write: da memoria centrale a quella di massa. Lo scheduler autorizza la read/write di un blocco. Dal momento che le transazioni devono soddisfare la proprietà di atomicità gli unici schedule autorizzati dallo scheduler sono quelli seriali. Si parlerà di r(x) e w(x), dove x è una pagina, anche se viene trattato come dato numerico.

Controllo della concorrenza: architettura
pagine read(x) write(y) read(z) Database y z x z, x  x Scheduler  y y z Buffer di memoria centrale Scheduler: modulo del sistema che gestisce le operazioni di lettura e scrittura e decide se possono essere soddisfatte

Assunzione: operazioni atomiche
La Teoria del Controllo di Concorrenza considera le operazioni di Read e Write. Quindi assume che esse siano atomiche altrimenti, dovrebbe considerare le operazioni di piu’ basso livello che implementano Read e Write Read(x) (r(x)) - lettura dell’area di memoria contenente il dato x e restituisce il valore corrente di x nel DB Write(x, val) ( w(x)) scrittura dell’area di memoria contenente il dato x (l’intera pagina che lo contiene!) Questa assunzione permette di astrarre l’esecuzione delle transazioni a sequenze di Read e Write

Esecuzioni concorrenti

Anomalie delle transazioni concorrenti ……
Casi seriali: bot(T2) read (D,y) y=y+3 write(D,y) commit eot(T1) bot(T1) read(D,x) x=x+1 write(D,x) commit eot(T1) D(t0)=0 b(T1) e(T1) b(T2) e(T2) D=0 D=1 D=4

….Anomalie delle transazioni concorrenti ….
Casi seriali: bot(T2) read (D,y) y=y+3 write(D,y) commit eot(T1) bot(T1) read(D,x) x=x+1 write(D,x) commit eot(T1) D(t0)=0 b(T2) e(T2) b(T1) e(T1) D=0 D=3 D=4

...Anomalie delle transazioni concorrenti …
Transazione 1 Transazione 2 bot(T1) read(D,x) x=x+1 bot(T2) x=x+3 write(D,x) eot(T1) commit eot(T2) 1) Perdita di aggiornamento x=0 x=0 Dato x=0 l’esecuzione consecutiva dovrebbe produrre il valore 4 al seguito dell’ esecuzione delle transazioni. Invece perdo gli effetti di T1. x=1 x=0 x=0 x=3 x=1 x=3 b1 b2 e1 e2 x=3 t D=0 D=1 D=3

… Anomalie delle transazioni concorrenti …
x=0 Transazione 1 Transazione 2 bot(T1) read(D,x) x=x+1 write(D,x) bot(T2) x=x+3 abort eot(T1) commit 2) Lettura sporca x=0 x=1 Dato x=0, l’esecuzione consecutiva dovrebbe produrre il valore 3, in quanto una transazione è annullata. Invece perdo gli effetti di T1 x=1 x=1 x=1 x=4 x=4 b1 b2 e1 e2 t x=4 D=0 D=1 D=4 x=4

Transazione 1 Transazione 2 bot(T1) read(D,x) bot(T2) x=x+3 write(D,x) commit eot(T2) eot(T1) 3) Lettura inconsistente x=0 x=0 Dato x=0, T1 dovrebbe leggere sempre il valore 0 di x . Invece… T1 risente gli effetti di T2! x=0 x=0 x=3 x=3 x=3 x=3 b1 b2 e2 e1 x=3 D=0 D=3

Transazione 1 Transazione 2 bot(T1) read(X,x) bot(T2) read(Y,y) y=y-100 read(Z,z) z=z+100 write(Y,y) write(Z,z) commit s=x+y+z eot(T2) 4) Aggiornamento Fantasma x=300 Consideriamo il vincolo di integrità: x+y+z=1000, ed i valori iniziali: x(t0)=300, y(t0)=300, z(t0)=400 Nessuna delle due transazioni viola il vincolo d’ integrità … Invece gli effetti della concorrenza alterano il vincolo! y=300 y=300 y=200 z=400 z=500 y=200 z=500 z=500 b1 b2 e2 e1 s= =1100 S=1000 S=1100

Locking Il DBMS gestisce problemi sulla DB, dovuti alla concorrenza, garantendo la proprietà di isolamento. Infatti la proprietà di isolamento di una transazione garantisce che essa sia eseguita come se non ci fosse concorrenza Obiettivo: assicurare schedule serializzabili delle transazioni Implementazione: ritardare le operazioni che possono alterare la serializzabilita’ ponendo blocchi (locks) sui dati condivisi

Concetti di schedulazione
Scheduler: modulo del sistema che gestisce le operazioni di lettura e scrittura e decide se possono essere soddisfatte. Tale scelta si bassa sull’ obbiettivo di evitare le problematiche viste. La schedulazione rappresenta la sequenza delle operazioni di input/output effettuate dalle transazioni concorrenti: S1: r1(x) r2(z) w1(x) w2(z) dove r1, w1  T1 r2, w2  T2 T1 legge x T2 legge z T2 scrive z T1 scrive x

Assunzioni si considerano le sole operazioni di lettura e scrittura, omettendo qualsiasi manipolazione dei dati bot e eof vengono omessi non si conosce a priori l’esito della transazione supponiamo che una transazione non legga o scriva più di una volta la stessa informazione

Teoria del controllo di concorrenza…
Una transazione include letture e scritture caratterizzate da uno stesso indice. Una transazione T1 e’ rappresentata in questo modo: r1(x)r1(y)w1(x)w1(y). Dato un insieme di transazioni T1, T2,… , Tn, una sequenza S di esecuzione di azioni di tali transazioni che rispetta l’ ordine temporale della loro esecuzione (cioè t\c se l’ azione a viene prima dell’ azione b in Ti, allora a viene prima di b anche in S) viene detta schedule. Uno schedule S1 rappresenta, quindi, la sequenza di operazioni di ingresso/uscita concorrenti ( le transazioni avvengono in modo concorrente quindi le letture e scritture sono richieste in istanti successivi da diverse transazioni ): S2 = r1(x)r2(z)w1(x)w2(z)

Teoria del controllo di concorrenza …
Le operazioni compaiono nello schedule come esse vengono eseguite sulla base di dati Il controllo di concorrenza ha lo scopo di accettare alcuni schedule e rifiutarne altri, in modo che non si verificano anomalie. In questo caso si considerano gli schedule commit-proiezione, che includono solo transazioni che producono commit (eliminando le transazioni che contengono abort). questa assunzione è inaccettabile nella pratica perchè non includerebbe l’ anomalia da lettura sporca.

Scheduler Lo scheduler fa parte del gestore della concorrenza, effettua il compito di coordinare le esecuzioni parallele delle transazioni (accettando quelle che non provocano problemi e rifiutando tutte le altre) ed opera cosi: accoglie una transazione e le assegna un identificatore unico Comanda al buffer manager del DBMS di leggere/scrivere sul DB secondo una particolare sequenza Non è in grado di interpretare le specifiche operazioni sui dati in memoria locale tiene traccia di tutte le operazioni compiute accetta o rifiuta le operazioni progressivamente richieste dalle transazioni produce uno schedule che non contiene i problemi esposti.

Principi fondamentali del controllo della concorrenza
Obiettivo: rifiutare le schedulazioni che provocano i quattro tipi di anomalie. Schedulatore: componente che accetta o rifiuta le operazioni richieste dalle transazioni.

w0(x) w0(z) r2(x) r1(x) r1(z) w1(x) r3(z) w3(z)
Principi fondamentali del controllo della concorrenza Schedule seriale: “tutte le azioni di una transazione compaiono in sequenza senza essere intercalate da azioni di altre transazioni” w0(x) w0(z) r2(x) r1(x) r1(z) w1(x) r3(z) w3(z) Uno schedule è serializzabile se l’ esito della sua esecuzione è lo stesso che si avrebbe se le azioni in esso contenute fossero eseguite in almeno una qualunque delle possibili sequenze seriali costituite dalle stesse transazioni. Più precisamente, uno schedule S su T1, T2,…, Tn è serializzabile se esiste uno schedule seriale su T1, T2,…, Tn equivalente ad S

Studio della serializzabilità
Lo scheduler è il modulo del sistema che ha il compito di accettare o rifiutare i schedule. Gli unici schedule accettabili sono quelli che non provocano i 4 tipi di anomalie viste in precedenza, garantendo cosi la proprietà di isolamento. Per garantire l’isolamento è necessario garantire la serializzabilità di un insieme di transazioni. Lo studio della serializzabilità prevede: – Analisi delle possibili anomalie da non-isolamento che si possono verificare durante un’esecuzione concorrente – Introduzione di una notazione astratta e semplificata per rappresentare le transazioni – Definizione di diversi livelli di serializzabilità e corrispondenti tipi di anomalie che vi possono comparire – Definizione di proprietà e protocolli per garantire i diversi livelli di serializzabilità Per introdurre la nozione di stesso risultato si introducono diverse nozioni di equivalenza

Principi fondamentali del controllo della concorrenza
Idea base del nostro studio: individuare classi di schedule serializzabili che siano sottoclassi delle schedule possibili e la cui proprietà di serializzabilità sia verificabile con complessità ragionevole

Serializzabilità ed equivalenza tra schedule
La definizione generale di serializzabilità che abbiamo visto prima si basa sulla nozione di equivalenza tra due schedule: uno schedule è serializzabile se e solo se esso è equivalente ad uno schedule seriale sulle stesse transazioni. A secondo del livello di astrazione che adottiamo per caratterizzare gli effetti delle transazioni, otteniamo diverse definizioni della relazione della equivalenza, alle quali corrispondono diversi livelli di serializzabilità Data una certa definizione di equivalenza interessa definire due tipi di algoritmi: algoritmi per il test di equivalenza: dati due schedule, determina se essi sono equivalenti algoritmi per il test di serializzabilità: dato uno schedule, determina se esso è equivalente ad uno qualsiasi schedule seriale. Uno dei metodi più usati per gestire la concorrenza si bassa sulla definizione di regole di comportamento (protocolli dello scheduler) e delle transazioni che garantiscono un accettabile livello di serializzabilità, senza eseguire alcun test esplicito.

L’ esecuzione della commit-proiezione di uno schedule Si e’ corretta quando produce lo stesso risultato prodotto da un qualunque schedule seriale Sj delle stesse transazioni. In tal caso si dice SERIALIZABILE. Idea di base: individuare classi di schedule serializzabili che siano sottoclassi delle schedule possibili e la cui proprietà di serializzabilità sia verificabile con complessità ragionevole. Quindi richiede la nozione di equivalenza tra le transazioni: Equivalenza di VIEW Equivalenza di CONFLITTI Locking a due fasi (2PL) basata sulle marche di tempo (time stamping)

VIEW-SERIALIZZABILITA’ (VSR) si basa sul confronto delle sequenze di lettura/scrittura sullo stesso oggetto. in generale e’ un problema NP-hard CONFLITTO-SERIALIZZABILITA’ (CSR) si basa su confronto della sequenza delle operazioni di conflitto agiscono sullo stesso oggetto e almeno una di esse e’ una scrittura richiede la verifica dell’ aciclicità di un grafo nonostante la complessità del problema sia lineare e’ ancora inaccettabile soprattutto in contesti distribuiti

View-Equivalenza Relazione che lega coppie di operazioni di lettura e scrittura: una operazione di lettura ri(x) “legge da” una scrittura wj(x) ( legge-da ( ri(x), wj(x) ) ) quando wj(x) precede ri(x) e non vi e’ alcuna wk(x) compressa tra le due operazioni: w1(x)w1(z)r3(x), r3 legge da w1 Invece in w1(x)w2(x)r3(x), r3 legge da w2 ma non da w1 Formalmente legge-da (ri (x), wj (x))  ( wj(x) < ri(x) )    wn(x) | wj(x) < wn(x) < ri (x) S3 = w0(x) r2(x) w2(x) r1(x) w2(z) w0 (x) e r1(x) non sono in relazione visto che  w2(x) che precede r1(x) e viene effettuata dopo w0(x)

View-Equivalenza wi(x) e’ detta scrittura finale se e’ l’ ultima scrittura sull’ oggetto x che appare nello schedule: S4 = w3(x)w1(x)r2(x)w3(z), w3 non e’ la scrittura finale sull’ oggetto x, w1 e’ la scrittura finale di x mentre w3 e’ la scrittura finale sull’ oggetto z

View-Equivalenza Def di view-equivalenza: Due schedule Si e Sj sono detti view-equivalenti (denotati con Si V Sj) se possiedono la stessa “legge-da” e la stessa scrittura finale su tutti gli oggetti. Def di view-serializzabilità: Uno schedule viene detto view-serializzabile se è view-equivalente ad un generico schedule seriale. denotiamo con VSR la classe degli schedule view-serializzabili.

Esempio 1 Consideriamo gli seguenti schedule: leggeda ultima scrittura
S5 : w0(x)r2(x)r1(x)w2(x)w2(z) S6 : w0(x)r1(x)r2(x)w2(x)w2(z) S5 V S6 (S5 e S6 sono view-equivalenti) dal momento che gli due schedule hanno la stessa relazione “legge-da” e le stesse scritture finali. S6 è uno schedule seriale poiché le azioni di tutte le transazioni sono in sequenza quindi S5 è view-serializzabile legge-da(S5) = {(r2(x),w0(x)), (r1(x), w0(x))} ultima scrittura di x in S5: w2, ultima scrittura di z in S5: w2 legge-da(S6) = {(r1(x),w0(x)), (r2(x), w0(x))} ultima scrittura di x in S6: w2, ultima scrittura di z in S6: w2

Esempio 2 leggeda ultima scrittura
S7 : w0(x)r1(x)w1(x)r2(x)w1(z) S8 : w0(x)r1(x)w1(x)w1(z)r2(x) legge-da(S7) = {(r1(x),w0(x)), (r2(x), w1(x))} ultima scrittura di x in S7: w1, ultima scrittura di z in S7: w1 legge-da(S5) = {(r1(x),w0(x)), (r2(x), w1(x))} ultima scrittura di x in S8: w1, ultima scrittura di z in S8: w1 S7 V S8 (S7 e S8 sono view-equivalenti) dal momento che gli due schedule hanno la stessa relazione “legge-da” e le stesse scritture finali. S8 è uno schedule seriale poiché le azioni di tutte le transazioni sono in sequenza quindi S7 è view-serializzabile

legge-da(S6) = {(r1(x),w0(x)), (r2(x), w0(x))} S6 : w0(x)r1(x)r2(x)w2(x)w2(z) S7 : w0(x)r1(x)w1(x)r2(x)w1(z) ultima scrittura di x in S6: w2, ultima scrittura di z in S6: w2 legge-da(S7) = {(r1(x),w0(x)), (r2(x), w1(x))} ultima scrittura di x in S7: w1, ultima scrittura di z in S7: w1 S6 V S7 visto che non hanno la stessa relazione “legge-da” ne le stesse scritture finali

legge-da(S9) = {(r1(x),w0(x)), (r2(x), w0(x))} S9 : w0(x) r1(x) r2(x) w2(x) w2(z) S10 : w0(x) r2(x) w2(x) r1(x) w2(z) ultima scrittura di x in S9: w2, ultima scrittura di z in S9: w2 legge-da(S10) = {(r2(x),w0(x)), (r1(x), w2(x))} ultima scrittura di x in S10: w2, ultima scrittura di z in S10: w2 S9 V S10 visto che non hanno la stessa relazione “legge-da”

Non view-serializzabilità
In generale, per dimostrare la non view-serializzabilità occorre permutare in tutti i possibili modi le transazioni presenti negli schedule seriali e confrontarli con lo schedule iniziale S. S = r1(x) r2(x) w1(x) w2(x) S’ = r1(x) w1(x) r2(x) w2(x) S” = r2(x) w2(x) r1(x) w1(x)

View-Equivalenza Determinare la view-equivalenza e’ un problema con complessità lineare. Determinare se uno schedule e’ view-equivalente ad un qualsiasi schedule seriale e’ un problema NP-hard. E’ conveniente confrontare tra loro due schedule. Se non viene fornito uno schedule di confronto, invece, bisogna confrontare lo schedule con tutti gli schedule seriali ottenuti permutando tutte le possibili transazioni in esso contenuto. Si preferisce, quindi definire una condizione di equivalenza più ristretta, che non copra tutti i casi di equivalenza, ma possa essere usata nella pratica.

Esercizio Per ognuno dei seguenti schedule:
S1: w0(x)r2(x)r1(x)w2(x)w2(z) S2: w0(x)r1(x)r2(x)w2(x)w2(z) S3: r1(x)r2(x)w2(x)w1(x) S4: r1(x)r2(x)w2(x)r1(x) Dire se è view-serializzabile o no. Per quelli per i quali si risponde che sono view-serializzabili, motivare la risposta positiva. Per quelli per i quali si risponde che non sono view-serializzabili, illustrare quale anomalia presentano

Soluzione esercizio (1)
S2: w0(x)r1(x)r2(x)w2(x)w2(z) È uno schedule seriale. In quanto tale è banalmente view-serializzabile (perché view-equivalente a se stesso) S1: w0(x)r2(x)r1(x)w2(x)w2(z) S1 e S2 hanno: le stesse scritture finali: w2(x) e w2(z); la stessa legge-da: {(r2(x),w0(x)), (r1(x),w0(x))}

S3: r1(x)r2(x)w2(x)w1(x) Per essere view-serializzabile dovrebbe esistere uno schedule seriale e view-equivalente a S3 tale da avere come scrittura finale w1(x) e come relazione legge-da l’ insieme vuoto e supponiamo che esista un schedule siffatto. Perché w1(x) sia la letura finale di S, T1 deve essere l’ ultima transazione di S e quindi: S: r2(x)w2(x) r1(x)w1(x) Ma allora la relazione legge-da di S è costituita dalla coppia (r1(x), w2(x)). Assurdo. Si ha che in effetti che S3 presenta un’ anomalia da perdita di aggiornamento, in quanto T1 e T2 leggono lo stesso valore iniziale per x, e, dopo che T2 scrive il nuovo valore, tale valore è soprascritto da T1, in modo tale che l’ aggiornamento per opera di T2 sia “perso”

S4: r1(x)r2(x)w2(x)r1(x) non è serializzabile in quanto, per esserlo uno fra i seguenti schedule seriali dovrebbe essere view-equivalente ad S4, dove indichiamo con r’1(x) la seconda lettura di x per opera di T1: S’ : r2(x)w2(x)r1(x)r’1(x)  legge-da = {(r1(x),w2(x)), (r’1(x), w2(x))} S’’: r1(x)r’1(x) r2(x)w2(x)  legge-da = {} Con la relazione legge-da di S4 legge-da = {(r’1(x), w2(x))} Non esiste nessun schedule seriale view-equivalente ad S4! S4 presenta un anomalia da lettura sporca, in quanto T1 legge due valori diversi per x, pur non avendo effettuato nessuna modifica su di esso

Grafi orientati: terminologia
Un grafo orientato G è una coppia (V, E) dove V è un insieme non vuoto, E è una relazione su V, ossia un insieme di coppie ordinate di elementi di V Gli elementi di V sono i vertici, gli elementi di E sono gli archi

Grafo orientato: terminologia
In un grafo orientato G = (V,E): un vertice v è adiacente a u se c’è un arco (u,v)  E. Diciamo che l’arco (u,v) esce da u ed entra in v. Un cammino di lunghezza k da u a u’ è una sequenza di vertici v0= u, v1,…,vk = u’, tali che (vi-1, vi)  E per i =1,…,k Il cammino è semplice se tutti i vi sono distinti Diciamo che u è raggiungibile da u’ se c’è un cammino da u’ a u. Un cammino <v0, v1,…,vk> forma un ciclo se v0 = vk e k > 0 Il ciclo è semplice se v1,…,vk sono distinti

Grafo orientato: terminologia
1 2 3 4 5 V = {1,2,3,4,5} E = {(1,2), (1,3),(1,4),(2,2),(2,4),(3,1),(3,2),(4,3),(5,4)} Il Grafo ha 5 vertici , 9 archi e presenta 2 cicli ({1,4,3} e {4,3,2})

Conflict-Equivalenza
Si dice che un azione ai è in conflitto con l’ azione aj, (dove i≠j, il che significa che apartengono a diverse transazioni), se entrambe operano sullo stesso oggetto e almeno una di esse è una write: conflitti di lettura-scrittura e scrittura-scrittura. r2(x) w1(x) è un conflitto lettura-scrittura w2(x) w1(x) è un conflitto scrittura-scrittura r2(x) w2(x) non è un conflitto (operazioni della stessa transazione)

Primo modo Un modo per dimostrare che due schedule Si ed Sj sono conflict-equivalenti notazione (Si c Sj) è quello di dimostrare che Si può essere trasformato in Sj mediante una sequenza di scambi (swaps) tra azioni consecutive non in conflitto tra loro.

Esempio S=r1(x)w1(x)r2(x)w2(x)r1(y)r2(y)w2(y) è conflict-equivalente a S’=r1(x)w1(x)r1(y)w1(y)r2(x)w2(x)r2(y)w2(y) perche’ puo’ essere trasformato in S’ mediante la seguente sequenza di scambi: r1(x)w1(x)r2(x)w2(x)r1(y)w1(y)r2(y)w2(y) r1(x)w1(x)r2(x)r1(y)w2(x)w1(y)r2(y)w2(y) r1(x)w1(x)r1(y)r2(x)w2(x)w1(y)r2(y)w2(y) r1(x)w1(x)r1(y)r2(x)w1(y)w2(x)r2(y)w2(y) r1(x)w1(x)r1(y)w1(y)r2(x)w2(x)r2(y)w2(y)

Notate che: se due azioni consecutive appartengono a due transazioni non sono in conflitto, allora possono essere scambiate senza alterare l’ effetto dello schedule due azioni consecutive che appartengono alla stessa transazioni non possono essere scambiate , perche’ l’ effetto della transazione potrebbe cambiare Due azioni consecutive che appartengono a transazioni diverse e sono in conflitto tra loro non possono essere scambiate

Secondo modo: Un altro modo per dimostrare la conflict-equivalenza tra due schedule e’ il seguente: Si dice che uno schedule Si è conflict-equivalente con uno schedule Sj (notazione Si c Sj) se presentano le stesse operazioni ed ogni coppia di operazioni in conflitto è nello stesso ordine.

Conflict-Serializzabilita’
VSR CSR Uno schedule risulta conflict-serializzabile, se esiste uno schedule seriale ad esso conflict-equivalente. CSR è la classe di tutti gli schedule per cui esiste uno schedule seriale conflict-equivalente. La classe degli schedule CSR è strettamente inclusa in quella dei VSR. La conflict serializzabilità è condizione sufficiente ma non necessaria per la view-serializzabilità. In parole povere, esistono schedule che sono view serializzabili ma non sono conflict serializzabili

Esempio 1 (dimostrare la conflict–equivalenza 2o modo)
Dati due schedule bisogna domandarsi: i due schedule operano sugli stessi oggetti ? in ciascun schedule almeno una delle operazioni e’ di scrittura ? Dopodiche’ si trovano tutte le coppie di conflitto per tutti gli oggetti S11 : w0(x)r1(x)w0(z)r1(z)r2(x)r3(z)w3(z)w1(x) S12 : w0(x)w0(z)r2(x)r1(x)r1(z)w1(x)r3(z)w3(z) S11(x)= { (w0,r1),(w0,r2),(w0,w1),(r2,w1)} S11(z)={(w0,r1),(w0,r3),(w0,w3),(r1,w3)} S12(x)={(w0,r2),(w0,r1),(w0,w1),(r2,w1)} S12(z)={(w0,r1),(w0,r3),(w0,w3),(r1,w3)}

E’ possibile determinare se uno schedule è conflict-serializzabile mediante il cosiddetto grafo dei conflitti. Ad ogni transazione dello schedule corrisponde un nodo del grafo Grafo dei conflitti: i nodi del grafo identificano le transizioni Ti dello schedule T0 T3 T1 S11 : w0(x)r1(x)w0(z)r1(z)r2(x)r3(z)w3(z)w1(x) T2

Grafo dei conflitti: gli archi identificano i conflitti tra le azioni delle transizioni Ti. Cosi si traccia un arco fra i nodi Ti e Tj se esiste il conflitto tra le azioni ai e aj. Inoltre l’ arco sara’ indirizzato da Ti a Tj se ai precede aj nello schedule. T0 T3 T1 S11 : w0(x)r1(x)w0(z)r1(z)r2(x)r3(z)w3(z)w1(x) T2 w0 in conflitto con r3 w0 in conflitto con w3 (esiste) r1 in conflitto con w3 w0 in conflitto con r1 (esiste) w0 in conflitto con r1 e con w0 che precede r1 w0 in conflitto con r2 e con w0 che precede r2 w0 in conflitto con w1 e con wo che precede w1 ma l’ arco esiste gia r2 in conflitto con w1

Algoritmo della conflict-serializzabilita’
L’ algoritmo per verificare se uno schedule e’ conflict-serializzabile : costruisci il grafo dei conflitti P(S) relativo ad S verifica se P(S) e’ aciclico Restituisci true se P(S) e’ aciclico, false altrimenti È immediato verificare che l’ algoritmo ha complessita’ polinomiale rispetto alla dimensione dello schedule S

Conflict-serializzabilita’
Abbiamo visto che uno schedule che è conflict-serializzabile è anche view-serializzabile. È importante osservare che, al contrario, che esistono schedule che sono view-serializzabili ma non sono conflict-serializzabili. Ad esempio r1(x)w2(x)w1(x)w3(x) è view-serializzabile ma non è conflict-serializzabile

Scheduler basato sulla conflict-serializzabilita’
Uno scheduler basato sulla conflict-serializzabilita’ riceve la sequenza di azioni delle transazioni attive, nell’ ordine concorrente in cui vengono proposte. mantiene il grafo dei conflitti associato Ogni volta che gli viene proposta una nuova azione, aggiorna il grafo dei conflitti dello schedule corrente, e se è stato introdotto un ciclo, annulla la transazione alla quale appartiene l’ azione che ha introdotto il ciclo altrimenti accetta l’ azione e continua Poiché mantenere il grafo delle precedenze puo’ essere molto costoso computazionalmente, la conflict-serializzabilita’ non è usata nei sistemi commerciali Tutta via, al contrario della view-serializzabilita’, la conflict-serializzabilita’ è utilizzata in applicazioni sofisticate in cui il controllo della concorrenza è affidato ad un sottosistema specializzato e tolto dalla giurisdizione del DBMS

Si dimostra che lo schedule è in CSR se e solo se il grafo è aciclico. Sebbene questo problema abbia ancora complessità lineare, determinare i grafi di conflitti in DB distribuite è troppo oneroso per le seguenti ragioni: Il grafo risultante può essere di dimensioni notevoli. La dinamicità vincola in alcuni casi la ricostruzione del grafo. Si sta operando ancora in un contesto commit-proiezione di schedule. I metodi di locking a due fasi e timestamp rimuovono le suddette assunzioni

Esercizio 1 (View-Equivalenza)
Si consideri il seguente schedule, dove ogni operazione ri/wi si intende effettuata dalla transazione Ti: S : r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) si dica se lo schedule è VSR oppure no, e perché, in termini delle relazioni “leggeda” e scrittura finale.

r1(x)r3(x)r2(x)r1(t)w1(r)r3(r)w1(y)w2(t)w2(z)w3(t)w1(t) Dimostrare che lo schedule è in VSR equivale a dimostrare che esiste un qualunque schedule seriale view-equivalente ad esso. Richiami: una operazione di lettura ri(x) “leggeda” una scrittura wj(x) ( leggeda = ( ri(x), wj(x) ) ) quando wj(x) precede ri(x) e non vi e’ alcuna wk(x) compressa tra le due operazioni wi(x) e’ detta scrittura finale se e’ l’ ultima scrittura sull’ oggetto x che appare nello schedule

S : r1(x)r3(x)r2(x)r1(t)w1(r)r3(r)w1(y)w2(t)w2(z)w3(t)w1(t) Soluzione 1: A causa della presenza della scrittura del dato r da parte della transazione T1, e la conseguente lettura del dato da parte della transazione T3 la relazione “legge-da” contiene la coppia (w1(r), r3(r)) L’ ipotetico schedule seriale view-equivalente deve quindi avere elencate prima le operazioni delle transazioni T1 e subito dopo quelle di T3 per avere la stessa relazione “legge-da”. S’ : r1(x)r1(t)w1(r)w1(y)w1(t)r3(x)r3(r)w3(t)r2(x)w2(t)w2(z) ma la relazione T1 è l’ultima a scrivere il dato t quindi l’ ipotetico schedule seriale view-equivalente deve avere elencate prima le operazioni delle transazioni T3 poi quelle di T1 per avere la stessa scrittura finale. ASSURDO

S : r1(x)r3(x)r2(x)r1(t)w1(r)r3(r)w1(y)w2(t)w2(z)w3(t)w1(t) Soluzione 2: permutare in tutti i possibili modi le transazioni presenti negli schedule seriali e confrontarli con lo schedule. r2(x) w2(t) w2(z) r1(x) r1(t) w1(r) w1(t) w1(y) w3(t) r3(r) r3(x). r1(x) r1(t) w1(r) w1(t) w1(y) r2(x) w2(z) w2(t) w3(t) r3(r) r3(x). Potrebbero esserci troppe permutazioni possibili

Homework Si consideri il seguente schedule, dove ogni operazione ri/wi si intende effettuata dalla transazione Ti: r1(x) r3(x) w3(x) r2(x) r2(v) r1(t) w1(r) r3(r) w1(y) w2(z) w3(t) w3(v) w1(t) w3(t) si dica se lo schedule è VSR, indicando (se esiste) un possibile schedule seriale equivalente. Si svolga l’esercizio, specificando le relazioni legge-da e scrittura-finale.

Locking Motivo: la view-serializzabilità e la conflict-serializzabilità non sono applicabili nei sistemi commerciali Obiettivo:assicurare schedule serializzabili delle transazioni Implementazione: ritardare le operazioni che possono alterare la serializzabilita’ chiedendo il permesso di operare su un elemento della DB, ponendo blocchi (locks) sui dati condivisi

Il lock: assunzioni Ciascuna transazione pone un lock (prenotazione) su ogni dato al quale intende accedere. la prenotazione va effettuata prima di leggere/scrivere su un dato. la transazione può ottenere il lock richiesto o resta in attesa di ottenerlo. ogni transazione rilascia il dato (unlock) dopo l’ uso

Locking di base (sintassi)
Indichiamo con : rl(x) un read lock sul dato x r(x) la lettura del dato x wl(x) il lock in scrittura del dato x w(x) la scrittura del dato x ru(x) e wu(x) sono i relativi unlock In generale indichiamo con opi(x) una operazione effettuata dalla transazione Ti

Lo stato dei dati Un dato puo trovarsi in uno dei seguenti stati:
libero read-locked (il dato x e’ soggetto ad un lock condiviso) write-locked (il dato x e’ soggetto ad un lock esclusivo)

Locking di base Il locking si basa sull’idea che tutte le operazioni di scrittura e lettura debbano essere protette tramite l’esecuzione di tre primitive: r_lock, w_lock, unlock. Vincoli per una transazione ben formata rispetto al lock: Ogni operazione di lettura deve essere preceduta da un r-lock e seguita da un unlock. Il lock è condiviso Ogni operazione di scrittura deve essere preceduta da un w_lock e seguita da un unlock. Il lock è esclusivo. Se la richiesta di lock non viene concessa, la transazione è posta in stato di attesa. L’attesa termina quando la risorsa viene sbloccata e diviene disponibile. I lock concessi sono tracciati in tabelle di lock. La tabella dei conflitti illustra la politica seguita dal lock manager nel concedere le risorse.

Locking condiviso ed esclusivo
locking condiviso: un rli(x) e’ sempre concessa se x è libero o read-locked (più transazioni possono porre un lock condiviso) ma negata se x è write-locked. locking esclusivo: wli(x) concessa solo se x è libero, ossia solo una transazione può scrivere un dato, escludendo tutte le altre. Se una transazione ha un write lock su x, allora nessun’altra transazione può avere alcun lock su x

Esempi di locking Siano rli[x], rui[x], wli[x], wui[x] operazioni di lock/unlock wl1[x] w1[x] rl2[x] r2[x] e’ impossibile wl1[x] w1[x] wu1[x] rl2[x] r2[x] e’ possibile

Gestione delle richieste di lock
Formato effettivo delle le operazioni di lock: Lock (trans-id, data-item-id, mode=r/w) Unlock (trans-id, data-item-id) Unlock (trans-id) Dove trans-id: identificativo della transazione data-item-id: identificatore del elemento x per il quale si richiede o si rilascia il lock mode = r/w indica se si tratta di un read o write lock

Gestione delle richieste di lock
Le transazioni che non ottengono un lock vengono poste in attesa. Lo scheduler (o lock manager, o data manager) gestisce una tabella di lock. Tabella di lock: contiene le richieste accettate e rifiutate. Ogni riga della tabella di lock contiene: il nome x del dato l’elenco delle transazioni che hanno ottenuto un lock (indicando di che tipo) l’elenco delle transazioni che sono state poste in attesa perchè non hanno ottenuto un lock (indicando di che tipo)

Il Lock Manager Il Lock Manager gestisce le operazioni
Lock(trans-id, data-item-id, mode=r/w) Unlock(trans-id, data-item-id) Unlock(trans-id) e memorizza i lock nella lock table. data item lista locks [Ti, r/w] lista d’ attesa x [T1,r], [T2,w] [T3,w] y [T4,w] [T5,w] [T6, r]

Il Locking di base non basta
Non garantisce la serializzabilita’ rl1[x] r1[x] ru1[x] wl1[x] w1[x] wu1[x] c1 rl2[y] r2[y] wl2[x] w2[x] ru2[y] wu2[x] c2 Eliminando i lock operations, abbiamo r1[x] r2[y] w2[x] c2 w1[x] c1 che non e’ serializzabile Possibile soluzione: ogni transazione acquisisce tutti i lock all’inizio e li rilasci tutti alla fine Problema: si limita troppo la concorrenza Soluzione: locking a due fasi

Two-Phase Locking (2PL)
Una transazione è two-phase locked (2PL) se: prima di leggere x, pone un read lock (r_locki) in x prima di scrivere x, pone un write lock (w_lockj) in x mantiene ciascun lock fino a dopo l’esecuzione dell’operazione sul dato e quindi ogni operazione di read è preceduta da un r_lock e seguita da un unlock ogni operazione di write è preceduta da un w_lock e seguita da un unlock dopo il primo unlock, non può porre nuovi locks

Per la serializzabiltà è necessario che il locking sia a due fasi. 2PL : Una transazione non può acquisire altri lock dopo averne rilasciato uno. si distinguono due fasi: una di acquisizione della risorsa e una di rilascio Se uno schedulatore usa transazioni ben formate, concede il lock in base ai conflitti, è a due fasi allora produce la classe delle schedulazioni 2PL

Two-Phase locking : stesso effetto di tutti i lock all’inizio della schedulazione, ma meno vincoli sulla concorrenza La transazione acquisisce man mano i lock necessari richiede un lock solo quando deve operare su quel dato, e non all’inizio; Nel frattempo effettua le operazioni sui dati; Rilascia gradualmente i lock, con la condizione che dopo il primo unlock non può più fare lock

Una transazione acquisisce i lock durante la fase crescente e li rilascia nella fase calante Esempio precedente: T2 e’ 2PL, ma non T1 perche’ ru1[x] precede wl1[x] Risorse Fase crescente: acquisizione dei lock per le risorse a cui si deve accedere Fase calante: i lock acquisiti vengono rilasciati Tempo

Esempio di 2PL DB SCHEDULER STRUTTURA DEI DATI
w_lock1(x) w1(x) w_lock2(x) w2(x) unlock2(x) unlock1(x) ERATTO w_lock1(x) w1(x) unlock1(x) w_lock2(x) w2(x) unlock2(x) GIUSTO r_lock1(x) r1(x) unlock1(x) …… w_lock1(x) w1(x) unlock1(x) …… r_lock1(x) r1(x)… w_lock1(x) w1(x)… ed eseguita da un unlock Ogni operazione di lettura è preceduta da un r_lock Ogni operazione di write è preceduta da un w_lock ed eseguita da un ulock Attenzione: l’ r_lock è condiviso dal momento che su un dato possono essere attivi contemporaneamente più lock. il w_lock è esclusivo dal momento che su un dato non possono essere attivi contemporaneamente più lock

Scheduler basato su lock esclusivi e su 2PL
Lo scheduler riceve le richieste di lock dalle transazioni e le concede in base a quelle già precedentemente richieste. Quando la richiesta di lock viene concessa allora si dice che la risorsa viene acquisita dalla transazione richiedente. All’ atto dell’ unlock viene rilasciata. Se la richiesta di lock non viene concessa la transazione viene messa in stato di attesa, aggiornando la lock table.

Comportamento del Lock Manager
Il Lock Manager riceve le primitive delle transazioni e concede le risorse secondo la tabella dei conflitti quando viene concesso il lock la risorsa viene acquisita quando viene eseguito unlock la risorsa viene rilasciata RICHIESTA STATO DELLA RISORSA LIBERA R_LOCKED W_LOCKED r_lock Ok No w_lock unlock ERRORE Ok DIPENDE Ok LIBERA

Osservazioni: le schedulazioni 2PL sono seriallizabili e strettamente incluse in CSR (Ogni schedule che rispetti il 2PL è serializzabile secondo la conflictequivalenza). esempio di schedulazione CSR, ma non 2PL S13: r1(x) w1(x) r2(x) w2(x) r3(y) w1(y) quanto detto finora vale nell’ ipotesi che nessuna transazione abortisca Tale ipotesi non si verifica in pratica occorre aggiungere un vincolo (locking a due fasi stretto)

Le classi 2PL e CSR Ogni schedule che rispetti i requisiti del protocollo di 2PL risulta anche uno schedule serializzabile rispetto alla conflict-equivalenza, ovvero che la classe 2PL è strettamente contenuta in CSR. Dim: 1) 2PL contenuta in CSR per assurdo. Sia che esista uno schedule S  2PL ma S CSR. Ma se SCSR, vuol dire che il grafo dei conflitti contiene almeno un ciclo per esempio T1, T2,…, Tn,T1. Da questo ciclo possiamo dedurre che esiste un conflitto tra le transazioni T1 e T2 il che vuol dire che esiste una risorsa su cui operano entrambe le transazioni. Affinché la transazione T2 possa procedere T1 deve rilasciare il lock sulla risorsa che provoca il conflitto. Lo stesso per le transazioni Tn, T1 e T1 per procedere deve aspettare che Tn rilascia la risorsa. Quindi la transazione T1 si trova contemporaneamente in due fasi: sia in quella crescente che calante. Assurdo.

Le classi 2PL e CSR VSR CSR 2PL 2) 2PL strettamente contenuta in CSR
Per far ciò basta dimostrare che esiste almeno uno schedule che appartiene alla classe CSR ma non alla classe 2PL, per esempio lo schedule S13: r1(x) w1(x) r2(x) w2(x) r3(y) w1(y),in cui la transazione T1 è CSR serializzabile rispetto alla sequenza T3,T1, T2. Lo stesso schedule non risulta però in 2PL dal momento che richiede, prima un lock esclusivo sulla risorsa x e successivamente un lock esclusivo sulla risorsa y. Ma a questo punto il lock sulla risorsa y non può essere fatto dal momento che la risorsa x è stata rilasciata. VSR CSR 2PL

Esercizio Si analizzi la seguente sequenza di azioni di un insieme di azioni di un insieme di transazioni, e si dica se essa costituisca uno schedule conflict serializzabile oppure no, e se essa possa o no dare luogo ad uno schedule che segue il protocollo 2PL. Motivare tutte e tre le risposte. S: r1(x)w2(x)r3(x)r1(y)r4(z)w2(y)r1(v)w3(v)r4(v)w4(y)w5(y)w5(z)

Poiché sappiamo che: Dato uno schedule in 2PL, allora tale schedule è conflict-serializzabile, e che Dato uno schedule conflict-serializzabile, allora tale schedule è in view-serializzabile Ci conviene a provare a vedere prima se S è in 2PL!

analizzando S ci aggiorgiamo che non esiste alcun modo per le transazioni di fare le operazioni di lock e unlock delle risorse in modo tale da rispettare il protocollo del 2PL. Infatti: perché T3 possa procedere con la lettura di x è necessario che la transazione T2 abbia rilasciato il lock su x (poiché T2 ha ottenuto il lock esclusivo in scrittura su x)  T2 entra pertanto in fase calante (di rilascio di lock) quando T3 legge x perché T1 possa procedere con la lettura di y è necessario che nessuna transazione detenga in quel momento il lock esclusivo in lettura su y  T2 non può detenerlo poiché T2 possa procedere con la scrittura di y è necessario che detenga il lock esclusivo su y  T2 dovrebbe richiedere il lock su y dopo che T1 ha letto y IMPOSSIBILE: T2 è gia in fase calante!

proviamo ora a costruire il grafo dei conflitti G(S) T1 T5 T4 T3 T2 Tale grafo è aciclico. S è pertanto conflict-serializzabile S è anche view-serializzabile! In particolare, uno schedule S’ seriale conflict equivalente (e quindi view-equivalente) ad s è il seguente: S’ : r1(x)r1(y)r1(v)w2(x)w2(y)r3(x)w3(v)r4(z)r4(v)w4(y)w5(y)w5(z)

2PL Rilasciamento della Commit-proiezione
Il 2PL si basa sulla commit-proiezione, ossia sull’ipotesi che tutte le transazioni facciano commit (e non abort) Occorre ora rilasciare questa ipotesi Se le transazioni possono fare abort, i problemi si complicano ed occorre porre condizioni addizionali al 2PL per evitare malfunzionamenti

Rilasciamento della commit-proiezione: Problemi
Consideriamo le due transazioni Ti e Tj. Se Tj legge da Ti e Ti fa abort, allora anche Tj deve fare abort (se no può presentarsi il problema delle “letture sporche”) Esempio - w1[x] r2[x] a1 vuol dire che T2 deve fare abort Ma se Tj ha gia’ fatto commit? Esempio - w1[x] r2[x] c2 a1 T2 non può fare abort dopo il commit

Recoverability L’esecuzione deve essere recoverable: Il commit di una transazione T deve essere successivo al commit delle transazioni da cui legge. Recoverable - w1[x] r2[x] c1 c2 Non recoverable - w1[x] r2[x] c2 a1 in altre parole si devono sincronizzare le operazioni delle transazioni 2PL non garantisce la recoverability

Recoverability: Problemi
La recoverability garantisce la coerenza d’uso dei dati, ma genera aborti a catena Gli aborti a catena (o cascading aborts o effetto domino) causano inefficienza perchè molte transazioni vengono uccise, perdendo il lavoro fatto.

Evitare gli aborti a cascata
Per evitare aborti a cascata, lo scheduler deve assicurare che le transazioni leggano solo da transazioni che hanno fatto commit Esempio evita cascading aborts: w1[x] c1 r2[x] permette cascading aborts: w1[x] r2[x] a1 Un sistema che evita cascading aborts garantisce la recoverability e si chiama sistema stretto (sistema che garantisce la strictness = no effetto domino)

Stricness Un sistema stretto consente di eseguire ri[x] o wi[x] solo se tutte le transazioni precedenti che hanno scritto x hanno gia’ fatto commit o abort. Esempi stretto: w1[x] c1 w2[x] a2 non stretto: w1[x] w2[x] … a1 a2 stretto: w1[x] w1[y] c1 w2[y] r2[x] a2 non stretto: w1[x] w1[y] … w2[y] a1 r2[x] a2 “Stricness” evita “cascading aborts” (effetto domino)

Gestione dell’ abort dopo un abort occorre annullare (undo) ogni operazione write, w[x, n], ripristinando la before image (=il valore di x prima dell’esecuzione di w[x]) Esempio: w1[x,2] scrive il valore “2” in x. inizialmente x = y = 0 w1[x,2] w1[y,3] c1 w2[y,1] r2[x] a2 abort T2 : si ripristina la before image di w2[y,2] e quindi y = 3

Osservazione: Brain Concurrency Control
Se l’utente vuole usare l’output della transazione T1 come input per la transazione T2, deve aspettare che T1 faccia commit prima di lanciare T2. Solo così e’ garantito che T1 venga effettivamente serializzata prima di T2. Infatti, i sistemi serializzano secondo i criteri visti e non secondo le intenzioni dell’utente: se l’utente lancia prima T1 e poi T2 (ma prima che T1 termini) l’ordine fra esse non è garantito.

Implementazione del Locking
Come fa il data manager a sapere quando li è consentito a rilasciare i locks? Di solito, il data manager mantiene i lock di ogni transazione finchè essa fa commit o abort. In particolare: rilascia i read locks appene riceve il commit rilascia i write locks solo quando accetta il commit, per garantire la strictness Il data manager implementa il locking così: includendo un lock manager generando un lock per ogni Read o Write prevedendo la gestione dei deadlocks (vedi più avanti)

Lock manager (o scheduler)
Il lock manager gestisce le operazioni Lock(trans-id, data-item-id, mode=r/w) Unlock(trans-id, data-item-id) Unlock(trans-id) e memorizza i lock nella lock table. data item lista locks [Ti, r/w] lista d’ attesa x [T1,r], [T2,w] [T3,w] y [T4,w] [T5,w] [T6, r]

Rappresentazione degli oggeti
Dalla memoria secondaria non si trasferiscono mai singole tuple, ma “pezzi” più ampi, in genere pagine Quindi, un dato x si rappresenta: indicando la pagina in cui si trova identificando x nella pagina (ad es. tramite la chiave)

Memorizzazione della lock table
Certo non viene memorizzata sequenzialmente: troppo lento cercare i lock su x per accesso sequenziale. Occorre una opportuna struttura dati in generale: tabella hash funzione di hash f applicata su x f(x) identifica la riga di x nella tabella di locking ed è detto data-item-id Il chiamante genera il data-item-id, applicando una funzione di hashing sul nome del dato Infatti, la lock table e’ hashed sul data-item-id Lock e Unlock vengono chiamati frequentemente. Devono essere molto veloci: < 100 istruzioni.

Timestamp Rimuovendo la condizione di commit-proiezione…
Otteniamo il 2PL stretto: i lock di una transazione possono essere rilasciati dopo aver correttamente effettuato le operazioni di commit/abort. Timestamp: Semplice ma meno efficace del 2PL vengono usati identificatori associati ad ogni evento temporale che definiscono un ordinamento totale sugli eventi

Timestamp Il controllo di concorrenza basato sui time-stamp avviene nel modo seguente: ad ogni transazione viene associata un evento (il time-stamp o ts) che rappresenta l’ inizio della transazione. Nel seguito per semplicità di notazione, assumiamo che il timestamp di ogni transazione coincida con il suo pedice, cioè ts(Ti) = i. In questo modo le transazioni possono essere considerate come ordinate secondo l’ ordine dell’ arrivo Ogni schedule che rispetta questo ordine è conflict-serializzabile, perché è equivalente allo schedule seriale corrispondente all’ ordinamento dei timestamp. Ad ogni oggetto vengono associati due indicatori : WTM(x): il ts della transazione con timestamp più alto che ha eseguito l’ultima scrittura su un oggetto RTM(x): il ts della transazione con timestamp più alto che ha eseguito l’ultima lettura

Timestamp Le richieste che arrivano allo scheduler sono del tipo read(x,ts) e write(x,ts) dove ts è il timestamp della transazione che esegue la lettura o la scrittura (ad ogni operazione viene assegnato il timestamp della transazione). read (x,ts): se ts < WTM(x), la transazione è uccisa. Se la transazione è accettata (ts > WTM(x)) allora RTM(x) aggiornato al massimo tra ts e RTM(x). write(x,ts): se ts < WTM(x) o ts < RTM(x), la transazione è uccisa. Se la transazione è accettata (ts > WTM(x) e ts > RTM(x)), WTM(x) è posto pari a ts.

Timestamp Osservazioni:
Ogni transazione non può leggere o scrivere un dato scritto da una transazione con timestamp superiore Ogni transazione non può scrivere un dato già letto da una transazione con timestamp superiore

Timestamp: un esempio Ricordate che:
read (x,ts): se ts < WTM(x), la transazione è uccisa. Se la transazione è accettata (ts > WTM(x)) allora RTM(x) aggiornato al massimo tra ts e RTM(x). write(x,ts): se ts < WTM(x) o ts < RTM(x), la transazione è uccisa. Se la transazione è accettata (ts > WTM(x) e ts > RTM(x)), WTM(x) è posto pari a ts. richieste risposte valori r(x,6) ok RTM(x)=6 WTM(x)=0 r(x,7) ok (ts > WTM(x)=0) RTM(x)=7 r(x,9) RTM(x)=9 w(x,8) no (ts < RTM(x)=9) T8 uccisa w(x,11) WTM(x)=11 r(x,10) no T10 uccisa ts > WTM(x)=0 ts > RTM(x)=9 ts < WTM(x)=10

Timestamp Il metodo TS comporta l’ uccisione di un grande numero di transazioni Metodo corretto solo sotto l’ ipotesi della commit-proiezione Per rimuovere l’ ipotesi della commit-proiezione bisogna “bufferizzare” le scritture: effettuarle in memoria e trascriverle nella memoria di massa dopo il commit Problema: le letture da parte di altre transizioni memorizzati nel buffer e in attesa di commit vengano messe in attesa della transazione scrivente

Timestamp Per migliorarlo:
Pre-write: simile ad un lock in scrittura. Vengono rimandate le letture che manderebbero in cattivo esito la scrittura fino a quando il valore non viene effettivamente scritto. La transazione t1 segnala l’intenzione di effettuare una scrittura RTM (x)=0 WTM(x)=0 RTM(x)=2 RTM(x)=3 RTM(x)=4 w1(x) r2(x) r3(x) r4(x) r2(x) r3(x) r4(x) w1(x) La transazione t1 viene uccisa visto che 1<RTM(x)=4

TS multiversioni Fa uso delle multiversioni: si introducono versioni diverse di un elemento in modo che un’ azione di lettura possa essere sempre effettuata leggendo la versione giusta rispetto al tempo logico determinato dai timestamp ogni volta che viene effettuata una scrittura, la vecchia coppia degli oggetti non viene persa ma viene creata una nuova N-esima coppia con un corrispondente timestamp WTMN(x) unica coppia di RTM(x) (globale) In un generico istante esistono N ≥ 1 coppie di ciascun oggetto x. In questo metodo le richieste di lettura non vengono mai rifiutate. Invece vengono dirette alla versione attuale (corretta secondo il timestamp della transazione richiedente). Le coppie vengono rilasciate quando non esistono più transazioni in lettura interessate al loro valore.

TS multiversioni Regole di comportamento:
read(x,ts): una lettura è sempre accettata. Ma se voglio leggere un dato x di una transazione di WTM(x) = k da quale coppia devo leggere? Se ts < WTMN(x) allora k = N altrimenti si sceglie una versione i t/c : WTMi(x) < ts < WTMi+1(x) write(x,ts): se ts < RTM(x) si rifiuta la richiesta altrimenti si aggiunge una nuova versione del dato con WTMN(x) = ts

Timestamp multiversioni
L’ idea di adottare più versioni è stata introdotta anche agli altri metodi di controllo di concorrenza e in particolare nel 2PL. Uso interessante delle multiversioni: si limita il numero massimo di coppie a due. Cosi si possono tenere una coppia precedente e una successiva ad ogni aggiornamento durante le operazioni di scrittura

Esercizio 1 WTM(x)=0 RTM(X) =0 WTM(t) =0 RTM(t) =0 WTM(r) =0 RTM(r) =0 WTM(y) =0 RTM(y) =0 RTM(z)=0 WTM(z)=0 r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t)

Soluzione: esercizio1 WTM(x)=0
RTM(X) =1 WTM(t) =0 RTM(t) =0 WTM(r) =0 RTM(r) =0 WTM(y) =0 RTM(y) =0 RTM(z)=0 WTM(z)=0 r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t)

Soluzione: esercizio1 WTM(x)=0

Soluzione: esercizio 1 WTM(x)=0

RTM(x) =3 WTM(t) =0 RTM(t) =1 WTM(r) =1 RTM(r) =3 WTM(y) =0 RTM(y) =0 RTM(z)=0 WTM(z)=0 r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t)

RTM(x) =3 WTM(t) =3 RTM(t) =1 WTM(r) =1 RTM(r) =3 WTM(y) =1 RTM(y) =0 RTM(z)=0 WTM(z)=2 r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) T1 uccisa

r1(B)w1(A)w2(B)w1(B)r2(A)
Esercizio 2 Si considerano due risorse A e B sulle quali opera un controllo di concorrenza basato su timestamp. Si asuma che i timestamp in lettura e in scrittura di ogni risorsa siano pari a 0 e che il sistema assegni ad ogni transazione il valore del clock al momento della prima azione della transazione. Indicare le azioni dello scheduler a fonte del seguente input: r1(B)w1(A)w2(B)w1(B)r2(A)

Soluzione esercizio 2 Prima che lo scheduler riceva l’ input, si ha:
WTM(A) = WTM(B) = RTM(A) = RTM(B) = 0 A fonte dell’ input dato, il sistema risponde come segue (richieste  risposte  aggiornamenti): r1(B)  ok  ts(T1)=1, RTM(B)=1 perché ts(T1) >= WTM(B) e RTM(B)=max(ts(T1),RTM(B)) w1(A)  ok  WTM(A)=1 perché ts(T1)>=WTM(A) e ts(T1)>= RTM(A) w2(B)  ok  ts(T2) = 3, WTM(B)=3 perché ts(T2)>=WTM(B) e ts(T2)>=RTM(B) w1(B)  t1 messa in attessa del rollback di T2, perché ts(T1)=RTM(B) e ts(T1)< WTM(B) r2(A)  T2 messa in attesa del rollback di T1 DEADLOCK

Confronto tra le classi di serializzabilità
Come abbiamo già dimostrato la classe VSR è quella più generale. La classe VSR inoltre include strettamente la classe CSR. Teorema: Le classi 2PL e TS presentano una intersezione non nulla ma nessuna presenta una relazione di inclusione con l’ altra. Dim: si dimostra costruendo dei schedule: che sono sia in TS che in 2PL che sono in TS ma non in 2PL e viceversa. CSR a sua volta include strettamente le classi 2PL e TS. VSR CSR TS 2PL

Confronto tra le classi di serializzabilità
conflitti Il seguente schedule è in VSR (view-serializzabile)? Basta dimostrare che è in CSR. r1(x)w1(x)r2(x)r3(x)w2(y)r1(z)w3(z)r3(t)w3(t)r4(t)w4(y)w5(y) Grafo dei conflitti T1 T5 T4 T3 T2 Grafo aciclico => Schedule CSR

Confronto tra le classi
Assunzione: Consideriamo, come prima, che l’ indice di ogni transazione è il suo timestamp. Cosi: r1(x) lo schedule visto in precedenza è in TS ? Timestamp(x)=1

richieste risposte valori r(x,1) ok w(x,1) WTM(x)=1 r(x,2) RTM(x)=2 r(x,3) RTM(x)=3 w(y,2) WTM(y)=2 r(z,1) RTM(z)=1 w(z,3) Ok WTM(z)=3 r(t,3) RTM(t)=3 w(t,3) WTM(t)=3 r(t,4) RTM(t)=4 w(y,4) w(y,5) WTM(y)=5 r1(x)w1(x)r2(x)r3(x)w2(y)r1(z)w3(z)r3(t)w3(t)r4(t)w4(y)w5(y) Lo schedule è quindi in TS perchè: Non vi è mai una transazione che tenta di leggere un valore scritto da una transazione con timestamp più grosso Non vi è mai una transazione che tenta di scrivere un oggetto letto o scritto da una transazione con ts maggiore

Lo schedule visto in precedenza è 2PL ? r1(x)w1(x)r2(x)r3(x)w2(y)r1(z)w3(z)r3(t)w3(t)r4(t)w4(y)w5(y) La transazione 1 legge l’oggetto x ed è poi costretta a rilasciarlo per la transazione 2 Poi essa acquisisce nuovamente l’oggetto z. Abbiamo quindi uno schedule TS ma non 2PL

Consideriamo lo schedule r1(x)w1(x)r2(x)w2(x) Questo schedule è sia in TS che in 2PL. Invece lo schedule r2(x)w2(x)r1(x)w1(x) Non è in TS visto che la transazione con timestamp 2 legge dalla transazione con timestamp 1. È in 2PL dal momento che le risorse vengono acquisite in modo ordinato.

Confronto tra 2PL e TS Osservazioni :
nel TS le transazioni vengono uccise e poi riavviate. Nel 2PL invece vengono poste in attesa. il restart usato dal TS costa in genere più dell’ attesa imposta dal 2PL l’ ordine di serializzazione nel 2PL è imposto dai conflitti, mentre nel TS è imposto dai timestamp stessi. la necessità di attendere l’ esito della transazione comporta l’ allungarsi del tempo di blocco in 2PL e la creazione di condizioni di attesa in TS Il metodo 2PL può presentare il problema del blocco critico (vedi avanti)

Meccanismi per la gestione dei lock
Lock manager: processo in grado da essere invocato da tutti i processi che intendono accedere alla DB. Procedure di accesso: r_lock(id, x, errcode, timeout) w_lock(id, x, errcode, timeout) unlock(id, x) Dove: id : identificativo dalla transzione; x: elemento per il quale si richiede o si rilascia il lock; errcode: valore restituito dal manager, =0 se la richiesta è stata soddisfatta ≠0 altrimenti; timeout: massimo intervallo di tempo che la procedura chiamante è disposta ad aspettare per ottenere il lock

Se la richiesta sull’ acquisizione di una risorsa viene soddisfatta il lock manager: tiene traccia del cambiamento dello stato della risorsa nelle sue tabelle interne e restituisce immediatamente il controllo al processo modesto tempo di ritardo introdotto sull’ esecuzione della transazione. Se la richiesta non può essere subito soddisfatta: il processo viene messo in coda. Ciò comporta una attesa arbitrariamente lunga e quindi il processo associato alla transazione viene sospeso. Appena una risorsa viene rilasciata, il lock manager controlla se esistono dei processi in attesa e la assegna al primo processo in coda

Efficienza del lock manager: Dipende dalla probabilità che le richieste di una transazione vanno messe in coda (conflitto) P = (k*m)/n dove k: numero di transazioni operanti sul sistema m: numero medio di risorse a cui accede una transazione n: numero totale degli oggetti presenti nella DB Quando scatta un timeout e la richiesta è ancora insoddisfatta allora: la transazione richiedente può eseguire un rollback (riparte dall’ inizio) la transazione decide di proseguire richiedendo nuovamente il lock riservando quelle acquisite finora

Struttura delle tabelle dei conflitti: per ogni oggetto del DB ci sono due bit per lo stato dell’oggetto (LIBERO, R_LOCKED, W_LOCKED) un contatore: numero di processi in attesa dell’ oggetto Visto che alle tabelle dei lock si accede molto frequentemente, il lock manager mantiene queste informazioni nella memoria centrale. Cosi si minimizzano i tempi di accesso

Lock gerarchico Tutte le tecniche teoriche viste funzionano indipendentemente dalla risorsa su cui viene effettuato il lock: tabelle, tuple, campi di singole tuple Granularità dei lock: si possono specificare lock a diversi livelli lock a livello molto alto (tabelle) limitano l’accesso concorrente su tuple diverse aumentando i conflitti. D’altra parte transazioni che effettuano consuntivi (solitamente veloci) hanno bisogno di lock su tabelle intere. Lock molto granulari renderebbero oneroso il lavoro del lock manager esponendolo a rischi di fallimento Per ovviare a questo problema si utilizza il lock gerarchico

lock gerarchico: la scelta della granulatità
Granularità - dimensione dei dati su cui fare lock ad es., files, pagine, record, campi Granularità grossolana implica: Sufficienti pochi lock, basso locking overhead lock su grosse porzioni di dati, alta probabilita’ di conflitti, quindi concorrenza effettiva bassa Granularità sottile implica: Occorrono molti lock, alto locking overhead conflitti solo quando due transazioni tentano di accedere concorrentemente proprio lo stesso dato

Multigranularity Locking (MGL)
Lock di differente granularita’ grosse query fanno lock su grosse porzioni di dati (ad es. tabelle), transazioni brevi fanno lock su pochi dati (ad es. righe) Il Lock manager non puo’ rilevare i conflitti! ogni data item (ad es. tabella o riga) ha un differente identificatore

Multigranularity locking è un “trucco” sfrutta la naturale struttura gerarchica dei dati prima del lock su dati di basso livello, si fa un intention lock sulla struttura di piu’ alto livello che li contiene (cioè segnala l’intenzione di effettuare operazioni). Cosi per richiedere un lock su un nodo si deve gia avere un lock sul nodo genitore ad es., prima di un read-lock su una, si fa un intention-read-lock sulla tabella che contiene la riga

DB Tab1 Tab2 Tabn Frammento1 Frammento2 Frammenton … Tupla1 Tupla2 Tuplan La gerarchia delle risorse che fanno parte di una DB. Livello 0 : DB Livello 1 : Tabelle Livello 2 : Frammenti Livello 3 : Tuple Ogni transazione può operare ad un livello prescelto della gerarchia, definendo in modo efficiente i lock di cui ha bisogno Transazioni per il backup dei DB possono operare anche lock a livello di DB

Lock gerarchico: le primitive di richiesta
Primitive condivise con il protocollo del lock XL: lock esclusivo. Corrisponde al write_lock del protocollo normale SL: lock condiviso. Corrisponde al read_lock del protocollo normale. Primitive specifiche della tecnica IXL: intenzione di bloccare uno dei “figli” del nodo attuale in modo esclusivo. ISL: intenzione di bloccare uno dei “figli” del nodo attuale in modo condiviso. SIXL: lock condiviso del nodo attuale e intenzione di bloccare in modo esclusivo uno dei figli. Blocca il nodo corrente ed esprime l’ intenzione di bloccare in modo esclusivo uno dei suoi “figli”

Lock gerarchico: le primitive di richiesta
DB Tab1 Tab2 Tabn Frammento1 Frammento2 Frammenton … Tupla1 Tupla2 Tuplan Consideriamo il caso in cui vogliamo bloccare in scrittura (lock esclusivo) una tupla della tabella (livello 3). Allora: bisogna richiedere un IXL al livello 0 (intenzione di bloccare uno dei figli della DB) una volta che la richiesta viene soddisfatta si chiede un IXL al livello 1 (intenzione di bloccare un figlio delle tabelle) e un IXL al livello 2 (intenzione di bloccare un figlio dei frammenti) dopo che le ultime richieste vengono soddisfate si richiede un XL (lock esclusivo) per la particolare tupla quando la transazione termina rilascia i lock nell’ ordine inverso

Lock gerarchico : le primitive
Quindi, in generale : si richiedono i lock a partire dal livello 0 (DB) i lock si rilasciano in modo bottom-up, dal nodo di granularità più piccola e risalendo lungo l’ albero si richiede un lock IXL, XL, SIXL se si possiede gia un lock ISL o XSL sul nodo padre il lock manager per decidere se accettare una richiesta di lock, in base allo stato del nodo e al tipo di richiesta, consulta una tabella nella quale vengono riportate tutte le regole di compatibilità

Lock gerarchico : tabella delle regole di compatibilità
Richiesta Stato della risorsa SL XL ISL IXL SIXL Ok No Ad es., ISL e’ in conflitto con XL, perche’ ISL segnala un r-lock su un dato piu’ interno, che ha ottenuto un w-lock sulla struttura che lo contiene.

Il Deadlock Esiste un insieme di transazioni concorrenti ognuna delle quali : Ha gia acquisito un lock su una o più oggeti È in attesa di un oggetto gia acquisito da un’ altra transazione Def: Un insieme di transazioni concorrenti è in deadlock se ogni transazione nell’ insieme sta attendendo un evento (rilascio di una risorsa) che può essere causato da una transazione dello stesso insieme Un insieme di transazioni è in deadlock se ogni transazione è bloccata, e lo rimarrà all’ infinito se il sistema non interviene.

Il Deadlock Un deadlock può avvenire solo quando le seguenti condizioni (necessarie) valgono simultaneamente: Mutua esclusione: solo una transizione alla volta può utilizzare un oggetto. Possesso e attesa: una transazione che possiede almeno un oggetto sta in attesa di acquisire oggetti aggiuntivi posseduti da altre transazioni Assenza di preemption: una risorsa può essere rilasciata da una transazione in modo volontario Attesa circolare:  un insieme di transazioni {T0, …, Tn} in attesa t/c: T0 sta attendendo un oggetto posseduto da T1, ..., Tn-1 sta attendendo un oggetto posseduto da Tn e Tn sta attendendo un oggetto posseduto da T0

Il Deadlock Il Deadlock è quindi un problema rilevante tipico dei sistemi concorrenti in cui si introducono attese. Si prendano due transazioni, t1: r(x) w(y) e t2: r(y) w(x). Con un protocollo di 2PL lo schedule sarà del tipo r_lock1(x),r_lock2(y),read1(x),read2(y),w_lock1(y),w_lock2(x). La transazione T1 aspetta che l’ oggetto y sia liberato da T2 La transazione T2 aspetta che l’ oggetto x sia liberato da T1 A questo punto nessuna delle transazioni riesce a procedere e il sistema è bloccato Per eliminare il deadlock: abort di una transazione

Il Deadlock: probabilità di avvenimento
N transazioni T tempo tra richieste di lock K lock per transazione D lockable data items Consideriamo N transazioni, ciascuna ottiene (in media) K/2 lock Quindi sono concessi in totale KN/2 lock Ciascuna richiesta ha probabilità KN/2D di conflitto con un lock esistente. Ciascuna transazione richiede K locks, quindi la sua probabilità di entrare in conflitto è K2N/2D. La probabilità di deadlock è' proporzionale a K4N/D2 Prob(deadlock) / Prob(conflitto) = K2/D

Il Deadlock: probabilità di avvenimento
Consideriamo una tabella che consiste di n tuple diverse con identica probabilità di accesso. Quindi la probabilità che due transazioni che operano un accesso vadano in conflitto è P1 = 1/n. La probabilità che si verifichi un secondo conflitto è P2 = 1/n2 (pari alla probabilità di un secondo conflitto), la probabilità che si verifichi un terzo conflitto è P3 = 1/n3 e cosi via. Quindi la probabilità di verificarsi un conflitto decresce in modo esponenziale con la crescita della lunghezza del blocco critico Conclusione: il numero totale di conflitti che si può verificare in un sistema reale è trascurabile Nel caso dei deadlock costituiti da coppie di transazioni, la probabilità di conflitto cresce linearmente col numero globale delle transazioni presenti nel sistema (k) e quadraticamente col numero medio di risorse cui ciascuna transazione fa accesso (m)

Il Deadlock: tecniche di risoluzione
Timeout Deadlock prevention (prevenzione) Rilevamento Evitare Ripristinare Far finta di niente

Il Deadlock: tecnica timeout
Le transazioni rimangono in attesa per un tempo prefissato (timeout) Scaduta l’attesa alla transazione viene data una risposta negativa per il lock richiesto Questo significa che per la transazione la condizione di attesa non viene verificata Problema : la scelta del valore di timeout Valore troppo basso : rischio di individuare come deadlock anche situazioni normali e quindi “uccidere” delle transazioni che andrebbero in buon fine Valore troppo alto : le transazioni bloccate restano troppo tempo in attesa.

Il deadlock: tecnica di prevenzione
Mai concedere un lock che puo’ portare al deadlock Tecnica spesso usata nei sistemi operativi Inutilizzabile nel 2PL, perche’ richiederebbe l’esecuzione seriale delle transazioni. Esempio per prevenire il deadlock, allo schedule rl1[x] rl2[y] wl2[x] wl1[y], il sistema nega rl2[y]

Il Deadlock: tecnica di prevenzione
1° Soluzione: richiedere il lock di tutte le risorse necessarie al inizio della transazione Problema: a volte non sono note a priori tutte le risorse necessarie. 2° Soluzione: le transazioni acquisiscono dei timestamp, e questa tecnica permette l’ attesa di una transazione Ti su una risorsa acquisita dalla risorsa Tj solo sotto determinate condizioni ( ad es. se i < j). Cosi il 50% delle transazioni che generano conflitto vengono messe in coda il restante vengono uccise. Ma quale transazioni uccidere ? Esistono tre tecniche per decidere: Preemptive Non-preemptive Uccidere le transazioni che hanno fatto meno lavoro

Il Deadlock: tecniche di prevenzione
Preemptive o politica interrompente: risolve il conflitto uccidendo la transazione che possiede la risorsa Non-preemptive: la transazione può essere uccisa solo al momento che fa una nuova richiesta Uccidere le transazioni che hanno fatto meno lavoro

Il Deadlock: tecniche di prevenzione
Uccidere la transazione che ha fatto meno lavoro Problema: starvation. Le transazioni possono ripartire e abortire all’infinito: mai uccidere la più vecchia T1 inizia. Poi T2 inizia. vanno in deadlock, e T1 (la piu’ vecchia) e’ abortita. T1 riparte, T2 continua, e vanno ancora in deadlock T2 (la piu’ vecchia) e’ abortita ... Soluzione: Scegliere come vittima la transazione piu’ giovane evita la ripartenza ciclica, perche’ la piu’ vecchia non viene mai abortita, e può infine terminare. È necessario garantire che ogni transazione può essere uccisa per un numero limitato di volte oppure Quando una transazione viene uccisa e poi ripartita utilizza il medesimo timestamp. In questo modo la transazione ha una priorità crescente Questa tecnica uccide, mediamente, una transazione ogni due conflitti (nota che la probabilità di un deadlock è inferiore alla probabilità di un conflitto)

Il Deadlock: tecnica di rilevamento
Si permette al sistema di entrare in uno stato di deadlock e Periodicamente si scorrono le tabelle di allocazione delle risorse alla ricerca di transazioni per rilevare eventuali situazioni di deadlock Il rilevamento viene fatto analizzando le relazioni di attesa fra le varie transazioni determinando se esistono cicli al Wait-for graph. il rilevamento di un blocco critico si bassa nel determinare se esiste un ciclo su un grafo, operazione la quale è efficiente

Il deadlock: tecniche di rilevamento
Grafo wait-for: Nodi: insieme delle transazioni Relazione Ti  Tj : la transazione Ti sta aspettando il rilascio di un oggetto posseduto da Tj. Formalmente: Archi = {Ti  Tj | Ti attende che Tj rilasci un lock} Teorema: Se c’e un deadlock, allora il Waits-for Graph contiene un ciclo. Periodicamente si controlla il grafo di attesa per trovare cicli nel grafo e quando si trova un deadlock, si seleziona una vittima dal ciclo e la si abortisce (vengono cancellati gli archi). Si seleziona una vittima che ha fatto poco lavoro (ad es., ha acquisito il numero minimo di lock).

Il Deadlock: tecniche di rilevamento
y T2 T3 x transazioni oggetti Una transazione richiede il lock su un oggetto Una transazione richiede il lock su un oggetto In questo caso  un ciclo. Infatti: T1 possiede un lock sull’ oggetto y e richiede un lock sull’ oggetto x T2 possiede un lock sull’ oggetto x e richiede un lock sull’ oggetto y T4 possiede un lock sull’ oggetto y e T3 richiede un lock sull’ oggetto x

Tecnologia di un data base server:
Gestione del buffer

Buffer manager Buffer: zona della memoria non persistente preallocata in modo che sia a disposizione del DBMS per i trasferimenti dalla memoria di massa a memoria centrale e viceversa. Tale area di memoria è condivisa da tutte le transazioni. Il buffer è organizzato in frames che sono pagine nella memoria centrale ciascuna della dimensione di un blocco (dai 2Kb ai 64 Kb) Essendo in memoria centrale la gestione delle sue pagine è molto più efficiente (op. a miliardesimo di secondo) rispetto alle pagine della memoria di massa (op. millesimi di secondo) Buffer manager: esegue il trasferimento effettivo (caricamento e scaricamento) delle pagine del DB dai dispositivo di memoria di base (in remoto) alla memoria centrale. Fornisce primitive per accedere alle pagine presenti nel buffer Realizza operazioni di ingresso/uscita come risposta alle primitive

Buffer manager: architettura
Database Management System flush Buffer di memoria centrale Scheduler Buffer Manager fix force use unfix primitive Database x z y t write, delete extend open, close y x z read read_seq write write_seq

Buffer manager: organizzazione
Buffer di memoria centrale: E’ il modulo di piu’ basso livello del data manager Nei DBMS relazionali viene chiamato RSS (Relational Storage System) Conosce l’organizzazione fisica delle pagine Conosce la disposizione delle tuple nelle pagine Usa un buffer manager per la gestione del trasferimento effettivo delle pagine Il buffer di memoria centrale è organizzato in pagine Dimensione della pagina = dimensione del blocco ingresso/uscita 2 Kbyte < dimensione pagina < 64 Kbyte Quando una pagina della memoria di massa è presente nel buffer, il DBMS effettua operazioni lettura/scrittura direttamente (vantaggio) Gestore dei buffer: gestisce il direttorio Direttorio: descrive il contenuto del buffer associando ad ogni pagina

Buffer manager: le primitive …
Primitive: operazioni del buffer manager per gestire operazioni di caricamento e scaricamento fix: richiede l’ accesso ad una pagina e la carica in memoria. Se la pagina non e’ gia presente nel buffer la cerca nella memoria centrale (lettura da disco). Restituisce alla transazione un puntatore ad una pagina del buffer. Al termine la pagina risulta caricata e allocata ad una transazione attiva. Operazioni svolte dalla primitiva: cerca la pagina tra quelli in memoria. Nel caso positivo l’ indirizzo della pagina viene restituito alla transazione richiedente se l’ esito della ricerca e’ negativo viene scelta una pagina nel buffer, possibilmente libera, e successivamente una pagina (vittima) da scaricare in memoria di massa. Se viene scelta una pagina non libera, essa deve essere riscritta in memoria di massa con una operazione flush vengono operate le conversioni di indirizzi in modo da identificare la pagina da caricare nel buffer

… Buffer manager: le primitive
use: utilizzata per accedere alla pagina caricata in memoria con fix confermando lo stato della pagina (allocata nel buffer e ad un transazione attiva) unfix: utilizzata per indicare al buffer che la transazione non utilizza piu la pagina force: provoca un trasferimento sincrono di una pagina al memoria centrale (transazione sospesa fino a fine trasferimento). In piu e’ una operazione di scrittura sulla memoria di massa flush: utilizzata dal buffer manager per transferire in modo asincrono le pagine che non sono piu allocate da una transazione attiva. Il trasferimento avviene quando il buffer manager non e’ impegnato con delle operazioni fix o force. Inoltre tale primitiva rende lo stato delle pagine come libere

Buffer manager: politiche di gestione
Politica steal: il buffer manager è in grado di selezionare come vittima una pagina attiva ed allocata ad un’ altra transazione. Con questa politica il buffer manager è in grado di scrivere le pagine direttamente nella memoria di massa. Quindi in caso di abort deve riscrivere il valore iniziale della pagina in fix viene utilizzata la politica no-steal = mai deallocare pagine attive (facile da utilizzare e da realizzare) Politica force: quando una transazione effettua un commit tutte le pagine attive sono trascritte in memoria di massa in unfix viene utilizzata la politica no-force = al contrario della politica force non riscrivere nel DB tutte le pagine attive al commit (garantisce maggior efficienza) Politica pre-fetching: il caricamento delle pagine viene anticipato rispetto alle richiesta delle transazioni. Applicabile solo nel caso in cui le richieste sono note a priori. Politica pre-flushing: scaricamento anticipato delle pagine rispetto al momento in cui una pagina viene scelta come vittima

Confronto tra steal/no-steal e force/no-force
Dal punto di vista del recovery, no-steal e force sono più semplici da realizzare: Con no-steal, non dobbiamo disfare (undo) le transazioni che fanno rollback Con force, non dobbiamo rifare (redo) le azioni di una transazione che ha eseguito il commit, ma i cui effetti non sono stati registrati nella base di dati a fronte di un guasto Tuttavia Con no-steal possiamo essere costretti a tenere nel buffer molte pagine attive Con force, si possono avere numerose operazioni di I/O La strategia steal, no-force è in realtà la più usata, perché assicura la maggiore efficienza del gestore del buffer

Relazione tra buffer manager e file system
File system: modulo del O.S. I DB usano le funzionalità dei file systems ma si creano una astrazione dei file in modo da garantire l’ efficienza (buffer) e transazionalità (controllore dell’ affidabilità). Operazioni offerte dai file system e utilizzate dai DB: create e delete: con assegnazione di numero di blocchi extend: estensione dei blocchi open(fileid, filename) e close: per caricare i file in memoria centrale read(fileid, block, buffer): accesso diretto ad un blocco di un file. read_seq(fileid, f-block, count, f-buffer): accesso sequenziale ad un numero fisso di blocchi di un file. F-block = primo blocco del file e f-buffer = prima pagina del buffer write, write_seq speculari di quelle funzioni read primitive per strutturare la memoria di massa (directory)

Tecnologia di un data base server:
Controllo di affidabilità (gestore del recovery)

Il gestore del recovery
È il modulo responsabile di: Eseguire l’ inizio delle transazioni Eseguire il commit delle transazioni Eseguire il rollback delle transazioni Ripristinare lo stato corretto della base di dati a fronte di guasti e malfunzionamenti Utilizza una struttura di dati complessa, chiamata file di log

Controllore della affidabilità
File di log: archivio persistente della DB che registra le varie azioni svolte dal DBMS Ogni azione di scrittura viene protetta tramite un azione sul log file che tiene traccia di tutte le operazioni fatte. In questo modo è possibile disfare le azioni svolte a seguito di malfunzionamenti, oppure rifare queste azioni nel caso in cui la loro buon fine sia incerta

Controllore della affidabilità
Garantisce l’ atomicità e la persistenza dei DB responsabile di realizzare i comandi begin transaction (B), commit work (C) e rollback work(A: abort) Responsabile di realizzare le primitive di ripristino (ripresa a caldo e ripresa a freddo) Riceve le richieste di accessi a pagine in lettura e\o scrittura Predispone i dati necessari per eseguire i meccanismi di ripristino (checkpoint e dump) Responsabile della scrittura del log nella memoria stabile

Controllore della affidabilità: architettura
fix force use unfix Database Management System flush Buffer di memoria centrale Buffer Manager x z y Procedure di ripristino Ripresa a caldo Ripresa a freddo Controllore della affidabilità begin commit abort Database x z y t Log read read_seq Scheduler write write_seq

Controllore di affidabilità: memoria stabile.
Memoria stabile: memoria ‘resistente’ ai guasti Stabilità della memoria: Volatile (λ = 10 3 ore): memoria centrale e registri – l’ informazione viene distrutta da qualsiasi guasto del sistema Non volatile (λ = qualche anno): dischi e nastri – l’ informazione sopravvive ai guasti del sistema ma no a quelli dell’ unità di memorizzazione Stabile (λ = 7*10 2 anni) – l’ informazione non viene mai distrutta – è un’ astrazione realizzata fisicamente con componenti ridondanti Nessuna memoria è cosi stabile di assicurare una probabilità nulla di fallimento. Invece rendiamo questa probabilità vicina a zero con l’ utilizzo di meccanismi di replicazione e protocolli di scrittura robusti.

Le strategie dipendono dal tipo di errore o guasto
Logico il programma che esegue la transazione non può proseguire a causa di un errore del tipo • Input errato • Eccezione • Dato inesistente • Divisione per zero • Overflow … Bisogna verificare il programma

Le strategie dipendono dal tipo di errore o guasto
Di sistema: L’ istanza di esecuzione del programma non può proseguire per problemi di sistema del tipo Conflitto di transazioni concorrenti. Deadlock Perdita del buffer, stato persistente intatto Problema principale -> Atomicità Strategia di recovery: fare periodicamente la “fotografia” della situazione (checkpoint) ripercorrere all’ indietro la storia dei cambiamenti di stato del DB Disfare (undo) alcune operazioni, ripeterne altre (redo) Utilizza informazioni sulle operazioni effettuate (log)

Tipi di errori o guasti Crash di sistema
Guasto HW o SW a livello del sistema di elaborazione • Guasto di una scheda • Mancanza di alimentazione • Problemi del sistema operativo Può andar perso il contenuto del buffer Guasto della memoria secondaria Può interessare • Qualche blocco • La “aratura” di gran parte del disco Viene perso il contenuto della DB Catastrofe fisica Incendio, allagamento ,terremoto, … SI SALVI CHI PUO’!

Strumenti per il recupero dai guasti
DUMP Scaricamento del contenuto dell’ intera memoria su altro supporto LOG (giornale) Registrazione sequenziale (in ordine temporale) su altro supporto di tutte le operazioni svolte sulla memoria (a partire dall’ ultimo DUMP) CHECKPOINT (Marca) Speciale segnalazione periodica dello stato delle transazioni in quell’ istante Memorizzata sul LOG

Organizzazione dei log
Il log è un file di cui è responsabile il controllore della affidabilità scritto in memoria stabile. Memorizzate azioni svolte dalle transazioni rispettando l’ ordine temporale. Il log ha un blocco corrente ed è l’ultimo ad essere allocato I record del log vengono scritti sequenzialmente nel blocco corrente, fino ad esaurimento del blocco e sono di due tipi: di transazione e di sistema. I record di transizione registrano le attività svolte da ciascuna transazione nell’ordine temporale di esecuzione. Cosi ogni transazione inserisce al log un record di begin, record relativi alle azioni effettuate (insert, delete, update) e un record di commit oppure di abort Record delle transazioni t1 t DUMP CHECKPOINT B U C Top del log

Organizzazione dei log
I record di log sono: Record di begin, commit ed abort con l’indicazione della transazione t (B(T), C(T), A(T)). Record di update con l’indicazione della transazione t, l’oggetto O che è oggetto dell’aggiornamento e i due valori Before State (BS) ed After State (AS), di O (U(T,O,BS,AS)) Record di insert e delete, uguali a quelli di update ma senza BS (insert) e AS (delete) (I(T,O,AS), D(T,O,BS)) Primitiva di undo: per disfare un’azione sull’oggetto O è sufficiente ricopiarvi il suo BS; nel caso di insert bisogna eliminarlo. Undo(Undo(A))=Undo(A) (idempotenza) Primitiva di redo: per ripetere un’azione sull’oggetto O è sufficiente ricopiarvi il valore AS; il caso di delete bisogna eliminarlo. Redo(Redo(A))=Redo(A)

Organizzazione dei log: DUMP e CHECKPOINT
I record di sistema indicano operazioni di DUMP e di CHECKPOINT. Il CHECKPOINT registra periodicamente quali transazioni sono attive distinguendole da quelle completate; tale operazione è coordinata con il buffer manager ed esegue due operazioni: per ogni transazione committed dopo il precedente checkpoint copia le pagine di buffer sulla memoria di massa (con la primitiva flush) Scrive (con force su memoria stabile) un record CK(T1,T2,… ,Tn) contenente gli identificatori delle transazioni T1,T2,… ,Tn attive (uncommitted) all’ atto della esecuzione del checkpoint Conseguenza: per tutte le transazioni T per cui Commit(T) precede CK(T1,T2,… ,Tn), non è necessario alcun redo in caso di guasto

Sequenza di checpoint: Sospende l’ esecuzione delle transazioni Flush del buffer (pagine attive non ancora trasferite di transazioni committed) Scrive il record CK(T1,T2,… ,Tn) su log in modo sincrono (force su memoria stabile) Riprende l’ esecuzione delle transazioni

Un dump è una copia all’ intero dello stato del DB L’ operazione di dump viene eseguita offline (nessuna transazione attiva) Produce un backup, cioè un salvataggio su memoria stabile Scrive (force su memoria stabile) un record di dump nel log che segnala in quall’ istante è fatta una coppia del DB

Record di end Alcuni sistemi registrano nel log anche il record di end per ogni transazione, che attesta che le operazioni di flush per una transazione sono terminate. in presenza del record di end, è possibile individuare una classe di transazioni per le quali non è necessario effettuare nessuna azione, né di undo né di redo. in genere il record di end non è previsto, e di seguito va ignorato.

Undo di un’ azione Ripristina lo stato di un oggetto O al tempo precedente rispetto all’ esecuzione di una azione update, delete: assegna il valore BS ad O delete: cancella O

Redo di un’ azione ripristina lo stato di un elemento O al tempo successivo rispetto all’ esecuzione di un azione insert, update: assegna il valore AS ad O delete: cancella O

Idempotenza di Undo e Redo
durante il ripristino, possono verificarsi errori può essere necessario eseguire ripetutamente le azioni associate a Undo e Redo Valgono le proprietà di idempotenza: (Undo(Undo(A)))= Undo(A) (Redo(Redo(A)))= Redo(A)

Atomicità delle transazioni
L’ esito di una transazione è stabilito quando viene scritto il record Commit(T) oppure Abort(T) nel log (cioè nella memoria stabile) Commit(T) viene scritto in modo asincrono (force) dal buffer nel log in memoria stabile Abort(T) viene scritto in modo asincrono (flush) dal buffer nel log in memoria stabile (per il recovery non è fondamentale sapere immediatamente che una transazione ha abortito) Per le transazioni che al momento di un guasto sono Uncommitted: è necessario disfare le azioni, perché non è noto quali azioni siano state effettuate sulla memoria di massa, ma deve essere garantita la atomicità  Undo Commited: è necessario rifare le azioni, per garantire la durabilità (commit significa che la transazione si è impegnata a eseguire tutte le azioni)  Redo

Politiche di scrittura dei record di log nella memoria stabile
Il controllore dell’affidabilità deve garantire che siano verificate due regole: WAL: write ahead Log (scrivi il log per primo) i record di log, in particolare quelli che contengono il BeforeState, vengono scritti dal buffer su memoria stabile prima dei corrispondenti record nella memoria di massa questo rende efficace la procedura di Undo, perchè un valore può sempre essere riscritto su memoria di massa utilizzando il BS scritto nel log in memoria stabile. In altre parole WAL consente di disfare scritture fatte da transazioni non ancora committed

Il recovery manager segue sempre questa regola: Commit-Precedence I record di log, per la parte AfterState, vengono scritti dal buffer su memoria stabile prima di effettuare il commit della transazione (e quindi prima di scrivere il record di commit nel log in memoria stabile) Questo rende efficace il Redo, perché se una transazione è committed al momento di un guasto, ma le sue pagine non sono ancora state scritte su disco, si può usare i valore AS che si trova nel log in memoria stabile. In altre parole la regola del Commit-Precedence consente di rifare transazioni che hanno fatto commit, anche se i loro effetti non sono stati ancora registrati in memoria di mass

In pretica vengono considerate versioni semplificate delle regole: Una versione semplificata di WAL impone che i record di WAL siano scritti prima dei corrispondenti record della base di dati Una versione semplificata di Commit-Precedence impone che i record di log siano scritti prima della effettuazione dell’ operazione di commit

Politiche di scrittura sulla memoria di massa
Per ciascuna delle tre tipologie di operazioni sulla base di dati Update Insert Delete il recovery manager deve eseguire delle politiche di esecuzione per la scrittura sulla memoria di massa Analizzeremo la situazione per l’ operazione di update, ma le considerazioni valgono per tutte le operazioni

Tre sono le possibili strategie di scrittura dei valori della base di dati nella memoria di massa, tutte coerenti con le regole WAL e Commit-Precedence Effetto immediato Gli update vengono effettuati sulla base di dati in memoria di massa immediatamente (i record di log vengono comunque scritti prima dei dati corrispondenti) Il buffer manager quindi si impegna (con force o flush) a scrivere sulla base di dati in memoria di massa prima del commit sul log In questo modo tutte le pagine della base di dati modificate dalla transazioni sono certamente scritte su memoria di massa

Effetto differito Gli update vengono effettuati sulla base di dati in memoria di massa solo dopo il commit della transazione e la conseguente scrittura del record di commit nel log I record di log vengono comunque scritti prima dei dati corrispondenti Effetto misto Sono possibili entrambe le politiche, in funzione della efficienza (il record di log di una operazione P viene comunque scritto prima dei dati scritti sulla base di dati dalla operazione P)

Esempi Immediata Differita Mista B(T) U(T,X,BS,AS) U(T,Y,BS,AS) C
Scritture nel log Immediata Scritture nel batabase w(x) w(y) B(T) U(T,X,BS,AS) U(T,Y,BS,AS) C Differita w(x) w(y) B(T) U(T,X,BS,AS) U(T,Y,BS,AS) C Mista w(x) w(y)

Modalità immediata La memoria di massa contiene valori AS provenienti da transazioni uncommitted Richiede Undo delle operazioni di transazioni uncommitted al momento del guasto Non richiede Redo (se nel log è presente il commit di T, le pagine sono state già scritte da T in memoria di massa) Dump Crash Nulla Undo CK T1 T2 T3 T4 T5

Modalità differita La memoria di massa non contiene valori AS provenienti da transazioni uncommitted Rende superflua la procedura di Undo (perché al momento dell’abort, nulla è stato fatto sulla memoria di massa) Richiede Redo CK Dump Crash T1 Nulla T2 Redo T3 Redo T4 Nulla T5 Nulla

Modalità mista La scrittura può avvenire in modalità sia immediata che differita, a scelta del gestore del buffer (e per questo è la più usata). In particolare, questa modalità consente l’ottimizzazione delle operazioni di flush Richiede sia Undo che Redo CK Dump Crash T1 Nulla T2 Redo T3 Redo T4 Undo T5 Undo

Gestione dei guasti Dal punto di vista di DBMS esistono due classi di guasti: Guasti del sistema: bachi S.W. , interruzione del funzionamento dei dispositivi che portano il sistema in uno stato di inconsistente  perdita del contenuto della memoria centrale (tutti i buffer), e mantengono valido il contenuto della memoria di massa (DB e log) Guasti di dispositivo: guasti relativi ai dispositivi di gestione della memoria di massa  perdita del contenuto della DB ma non del log (memoria stabile)

Gestione dei guasti Obbiettivi della procedura di ripresa:
Le transazioni attive al momento del malfunzionamento (che non sappiamo l’ esito a priori) si possono classificare in due categorie in base all’ informazione presente nel file di log Transazioni che hanno effettuato il commit  bisogna rifare le azioni per garantire la persistenza Transazioni che non hanno effettuato il commit  bisogna disfare le azioni in quanto non è noto quali azioni siano state realmente effettuate

Tipi di recovery Politica ideale di recovery: fail-stop  appena il sistema individua il guasto esso forza l’ arresto completo delle transazioni e il successivo ripristino del corretto funzionamento del sistema operativo (boot) seguendo un recovery. Dopodiché il sistema diventa nuovamente utilizzabile dalle transazioni A secondo del guasto esistono due tipi di recovery: In caso di guasto del sistema: Warm restart (ripresa a caldo) In caso di guasto del dispositivo: Cold restart (ripresa a freddo)

Warm restart Assumiamo la modalità mista. Il warm restart si compone di 5 fasi: 1. Si ripercorre il log all’indietro fermandosi all’ultimo checkpoint (il più recente) nel log 2. Si pone set(UNDO) = { transazioni attive al checkpoint } e set(REDO) = { } 3. Si analizza il log in avanti aggiungendo a set(UNDO) le transazioni con begin, e spostando in set(REDO) quelle che hanno eseguito il commit 4. Fase Undo: si ripercorre il log all’indietro disfacendo le transazioni nel set Undo fino al begin della transazione più vecchia (si può andare indietro prima dell’ultimo checkpoint) 5. Fase Redo: si ripercorre il log in avanti rifacendo le transazioni nel set Redo

Esempio di warm restart
B(T1) B(T2) U(T2, O1, B1, A1) I(T1, O2,A2) CK Crash B(T3) C(T1) T1 C B(T4) U(T3, O2, B3, A3) T2 U(T4, O3, B4, A4) CK(T2 ,T3 ,T4 ) T3 A C(T4) B(T5) T4 U(T3, O3, B5, A5) U(T5, O4, B6, A6) T5 C D(T3, O5, B7) A(T3) C(T5) I(T2, O6, A8)

Soluzione: ricerca dell’ ultimo checkpoint
B(T1) B(T2) UNDO = {T2 ,T3 ,T4} U(T2, O1, B1, A1) I(T1, O2,A2) CK Crash B(T3) C(T1) T1 C B(T4) U(T3, O2, B3, A3) T2 U(T4, O3, B4, A4) CK(T2 ,T3 ,T4 ) T3 A C(T4) B(T5) T4 U(T3, O3, B5, A5) T5 C U(T5, O4, B6, A6) D(T3, O5, B7) A(T3) C(T5) I(T2, O6, A8)

Soluzione: set(Undo) e set(Redo)
B(T1) 0. Undo = {T2, T3, T4}, Redo =  B(T2) 8. U(T2, O1, B1, A1) C(T4)  UNDO = {T2, T3}, REDO = {T4} B(T5)  UNDO = {T2, T3, T5}, REDO = {T4} C(T5)  UNDO = {T2, T3}, REDO = {T4, T5} I(T1, O2,A2) B(T3) C(T1) B(T4) 7. U(T3, O2, B3, A3) 9. U(T4, O3, B4, A4) 1. C(T4) 2. B(T5) 6. U(T3, O3, B5, A5) 10. U(T5, O4, B6, A6) 5. D(T3, O5, B7) A(T3) 3. C(T5) 4. I(T2, O6, A8)

Soluzione: fase di UNDO
B(T1) 0. Undo = {T2, T3, T4}, Redo =  B(T2) U(T2, O1, B1, A1) C(T4)  UNDO = {T2, T3}, REDO = {T4} B(T5)  UNDO = {T2, T3, T5}, REDO = {T4} C(T5)  UNDO = {T2, T3}, REDO = {T4, T5} I(T1, O2,A2) B(T3) C(T1) B(T4) U(T3, O2, B3, A3) D(O6) O5 = B7 O3 = B5 O2 = B3 O1 = B1 U(T4, O3, B4, A4) C(T4) Fase di UNDO B(T5) U(T3, O3, B5, A5) U(T5, O4, B6, A6) D(T3, O5, B7) A(T3) C(T5) I(T2, O6, A8)

Soluzione: fase di Redo
B(T1) 0. Undo = {T2, T3, T4}, Redo =  B(T2) U(T2, O1, B1, A1) C(T4)  UNDO = {T2, T3}, REDO = {T4} B(T5)  UNDO = {T2, T3, T5}, REDO = {T4} C(T5)  UNDO = {T2, T3}, REDO = {T4, T5} I(T1, O2,A2) B(T3) C(T1) B(T4) U(T3, O2, B3, A3) D(O6) O5 = B7 O3 = B5 O2 = B3 O1 = B1 O3 = A4 O4 = A6 U(T4, O3, B4, A4) C(T4) Fase di UNDO B(T5) U(T3, O3, B5, A5) U(T5, O4, B6, A6) D(T3, O5, B7) A(T3) Fase di REDO C(T5) I(T2, O6, A8)

Warm restart Garantisce atomicità e persistenza delle transazioni:
Atomicità: le transazioni in corso all’ istante del guasto lascino la DB nello stato iniziale o nello stato finale Persistenza: viene garantito che le pagine nel buffer relative alle transazioni completate ma non ancora trascritte in memoria di massa vengano effettivamente completate con una scrittura nella memoria di massa

Cold restart Comprende tre fasi:
Ricerca del record di dump più recente nel log, e caricamento del dump nella memoria di massa (in pratica si esegue una coppia selettiva dei frammenti danneggiati della DB) Forward recovery dello stato del dump: Si riapplicano tutte le azioni del log, nel loro ordine Si ottiene cosi lo stato della DB immediatamente precedente al crash 3. Si esegue un warm restart come descritto in precedenza

Esercizio: cold restart
si consideri il seguente log: DUMP, B(T1), B(T2), B(T3), I(T1,O1,A1), D(T2,O2,B2), B(T4), U(T4,O3,B3,A3), U(T1,O4,B4,A4), C(T2), CK(T1,T3, T4), B(T5), B(T6), U(T5,O5,B5,A5), A(T3), CK(T1,T4,T5,T6), B(T7), A(T4), U(T7,O6,B6,A6), U(T6,O3,B7,A7), B(T8), C(T7) A questo punto della esecuzione il sistema subisce un guasto di dispositivo. Si assuma che la modalità di scrittura nella memoria di massa sia quella mista, e quindi richieda sia undo sia redo.

Soluzione: ricostruzione del Dump
DUMP, B(T1), B(T2), B(T3), I(T1,O1,A1), D(T2,O2,B2), B(T4), U(T4,O3,B3,A3), U(T1,O4,B4,A4), C(T2), CK(T1,T3, T4), B(T5), B(T6), U(T5,O5,B5,A5), A(T3), CK(T1,T4,T5,T6), B(T7), A(T4), U(T7,O6,B6,A6), U(T6,O3,B7,A7), B(T8), C(T7) si accede all’ ultimo DUMP (la prima operazione riportata nel log), e si ricopia dal back-up in modo selettivola parte di base di dati danneggiata si ripercorre in avanti il log a partire da B(T1), e si eseguono tutte le operazioni fino a C(T7) si effettua un warm restart

Soluzione: sequenza di warm restart
B(T1) B(T2) B(T3) I(T1,O1,A1) D(T2,O2,B2) B(T4) U(T4,O3,B3,A3) U(T1,O4,B4,A4) C(T2) CK(T1,T3, T4) B(T5) B(T6) U(T5,O5,B5,A5) A(T3) CK(T1,T4,T5,T6) B(T7) A(T4) U(T7,O6,B6,A6) U(T6,O3,B7,A7) B(T8) C(T7) CK CK Crash T1 T2 T3 T4 T5 T6 T7 T8 C A A C

Soluzione: Checkpoint più recente
B(T1) B(T2) B(T3) I(T1,O1,A1) D(T2,O2,B2) B(T4) U(T4,O3,B3,A3) U(T1,O4,B4,A4) C(T2) CK(T1,T3, T4) B(T5) B(T6) U(T5,O5,B5,A5) A(T3) CK(T1,T4,T5,T6) B(T7) A(T4) U(T7,O6,B6,A6) U(T6,O3,B7,A7) B(T8) C(T7) UNDO = {T1,T4,T5,T6} CK T1 T2 T3 T4 T5 T6 T7 T8 C A A C

Soluzione: insiemi di UNDO e REDO
0. UNDO = {T1,T4,T5,T6}, REDO = {} B(T7)  UNDO = {T1,T4,T5,T6,T7}, REDO = {} B(T8)  UNDO = {T1,T4,T5,T6,T7,T8}, REDO = {} C(T7)  UNDO = {T1,T4,T5,T6, T8}, REDO = {T7} B(T1) B(T2) B(T3) I(T1,O1,A1) D(T2,O2,B2) B(T4) U(T4,O3,B3,A3) U(T1,O4,B4,A4) C(T2) CK(T1,T3, T4) B(T5) B(T6) U(T5,O5,B5,A5) A(T3) CK(T1,T4,T5,T6) B(T7) A(T4) U(T7,O6,B6,A6) U(T6,O3,B7,A7) B(T8) C(T7)

Soluzione: fase di UNDO
0. UNDO = {T1,T4,T5,T6}, REDO = {} B(T7)  UNDO = {T1,T4,T5,T6,T7}, REDO = {} B(T8)  UNDO = {T1,T4,T5,T6,T7,T8}, REDO = {} C(T7)  UNDO = {T1,T4,T5,T6, T8}, REDO = {T7} B(T1) B(T2) B(T3) I(T1,O1,A1) D(T2,O2,B2) B(T4) U(T4,O3,B3,A3) U(T1,O4,B4,A4) C(T2) CK(T1,T3, T4) B(T5) B(T6) U(T5,O5,B5,A5) A(T3) CK(T1,T4,T5,T6) B(T7) A(T4) U(T7,O6,B6,A6) U(T6,O3,B7,A7) B(T8) C(T7) 4. O3 = B7 5. O5 = B5 6. O4 = B4 7. O3 = B3 8. D(O1) UNDO

Soluzione: fase di REDO
0. UNDO = {T1,T4,T5,T6}, REDO = {} B(T7)  UNDO = {T1,T4,T5,T6,T7}, REDO = {} B(T8)  UNDO = {T1,T4,T5,T6,T7,T8}, REDO = {} C(T7)  UNDO = {T1,T4,T5,T6, T8}, REDO = {T7} B(T1) B(T2) B(T3) I(T1,O1,A1) D(T2,O2,B2) B(T4) U(T4,O3,B3,A3) U(T1,O4,B4,A4) C(T2) CK(T1,T3, T4) B(T5) B(T6) U(T5,O5,B5,A5) A(T3) CK(T1,T4,T5,T6) B(T7) A(T4) U(T7,O6,B6,A6) U(T6,O3,B7,A7) B(T8) C(T7) 4. O3 = B7 5. O5 = B5 6. O4 = B4 7. O3 = B3 8. D(O1) 9. O6 = A6 UNDO REDO

Tecnologia di un Database Server

Presentazioni simili

Presentazione sul tema: "Tecnologia di un Database Server"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back

Entrare

Autorizzarsi attraverso i social network:

Tecnologia di un Database Server

Presentazioni simili

Presentazione sul tema: "Tecnologia di un Database Server"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back