La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Tecnologia di un data base server: Controllo della Concorrenza Leonardo Mostarda Sea Lab.

Presentazioni simili


Presentazione sul tema: "Tecnologia di un data base server: Controllo della Concorrenza Leonardo Mostarda Sea Lab."— Transcript della presentazione:

1 Tecnologia di un data base server: Controllo della Concorrenza Leonardo Mostarda Sea Lab

2 Controllo della concorrenza La concorrenza delle transazioni consente un uso efficiente del DBMS, massimizzando il tps. Il controllo di concorrenza fa riferimento al livello più basso che attua il trasferimento di blocchi fra memoria centrale e memoria di massa (r/w). Le operazioni di r/w sono richieste dallo scheduler.

3 Controllo della concorrenza Con r(x) si indica la lettura dellarea di memoria contenente il dato x. Con w(x) si indica la scrittura dellarea di memoria contenente il dato x. x, y.. Sono oggetti del database su cui verranno effettuate operazioni numeriche Eseguire transazioni concorrenti aumenta il tps ma può causare problemi.

4 Anomalia delle transazioni concorrenti perdita di update bot r1(x) x=x+1 w1(x) commit bot r2(x) x=x+1 w2(x) commit Siano date le transazioni: t1: r1(x), x = x +1, w2(x) t2: r1(x), x = x +1, w2(x)

5 Anomalia delle transazioni concorrenti Letture sporche bot r1(x) x=x+1 w1(x) abort bot r2(x) x=x+1 w2(x) commit Siano date le transazioni: t1: r1(x), x = x +1, w2(x) t2: r1(x), x = x +1, w2(x)

6 Tecnologia data base server bot s=0 r1(x) r1(y) s = x + s s = y + s r1(z) s = z + s commit bot r2(z) z=z+10 r2(y) y = y -10 w2(y) w2(z) commit Tre oggetti x y z con definito il vincolo di integirtà x + y + z = 1000

7 Teria della concorrenza Modello formale di transazione: sequenza di azioni di lettura o scrittura, che si riconoscono eseguiti da una stessa transazione in quanto caratterizzati dallo stesso indice 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 lesito della transazione supponiamo che una transazione non legga o scriva più di una volta la stessa informazione S 9 = r 1 (x) r 1 (z) w 1 (x)

8 Teria della concorrenza Le transazioni avvengono in modo concorrente quindi le letture e scritture sono richieste in istanti successivi da diverse transazioni. Uno schedule rappresenta la sequenza di operazioni di read e write effettuate da transazioni concorrenti come w0(x) r1(x) w0(z) r1(z) r2(x) r3(z) w3(z) w1(x) Le operazioni compaiono nello schedule come esse vengono eseguite sulla base di dati Il controllore di concorrenza a il compito di accettare o meno un determinato schedule, al fine di evitare i problemi esposti.

9 Teria della concorrenza Lo scheduler effettua il compito di coordinare le esecuzioni parallele: 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.

10 Teria della concorrenza Consideriamo inizialmente transazioni con esito noto, questo consente di: eliminare le transazioni che contengono abort considerare solo transazioni che eseguono commit (schedule commit proiezione) Questo tipo di trattazione ha funzionalità teorica dato che: uno scheduler non conosce a priori lesito di una transazione non consente di trattare letture sporche

11 Teria della concorrenza Schedule seriale tutte le azioni di una transazione compaiono in sequenza senza essere intercalate da azioni di altre transazioni w 0 (x) w 0 (z) r 2 (x) r 1 (x) r 1 (z) w 1 (x) r 3 (z) w 3 (z) Lesecuzione di una commit-proiezione di uno schedule S è corretta quando produce lo stesso risultato di un qualunque schedule seriale contenente le stesse transazioni. In tal caso lo schedule si dice serializzabile. Per introdurre la nozione di stesso risultato si introducono diverse nozioni di equivalenza

12 View-equivalenza Definiamo una relazione leggeda che lega due operazioni: lettura e scrittura. Un operazione di lettura r i (x) leggeda w k (x) ( leggeda ( r i (x), w k (x) ) ) quando w k (x) precede r i (x) e non vi è nessun w n (x) compreso fra le due operazioni. Formalmente leggeda ( r i (x), w k (x) ) w k (x) < r i (x) w n (x) | w k (x) < w n (x) < r i (x) S 5 = w 0 (x) r 2 (x) w 2 (x) r 1 (x) w 2 (z) Non sono in relazione visto che w 2 (x) che precede r 1 (x) e viene effettuata dopo w 0 (x)

13 View-equivalenza Un operazione di scrittura w k (x) viene detta finale se è lultima scrittura sull oggetto x che appare nello schedule. w 0 (x) non è lultima scrittura sulloggetto x w 2 (x) è una scrittura finale sull oggetto x w 2 (z) è una scrittura finale sull oggetto z S 5 = w 0 (x) r 2 (x) w 2 (x) r 1 (x) w 2 (z)

14 View-equivalenza Due schedule vengono detti view-equivalenti ( S i V S k ) se possiedono la stessa relazione leggeda e le stesse scritture finali. Uno schedule viene detto view-serializzabile se è view equivalente ad un generico schedule seriale. VSR è linsieme degli schedule view- serializzabili.

15 View-equivalenza S 5 = w 0 (x) r 2 (x) w 2 (x) r 1 (x) w 2 (z) S 6 = w 0 (x) r 2 (x) w 2 (x) w 2 (z) r 1 (x) leggeda = { ( r 2 (x), w 0 (x) ) } leggeda = { ( r 2 (x), w 0 (x) ), ( r 1 (x), w 2 (x) )} leggeda = { ( r 2 (x), w 0 (x) ) } leggeda = { ( r 2 (x), w 0 (x) ), ( r 1 (x), w 2 (x) )} scrittura finale di x = w 2 (x) scrittura finale di z = w 2 (z) scrittura finale di x = w 2 (x) scrittura finale di z = w 2 (z) S 5 V S 6 visto che hanno la stessa relazione leggida e le stesse scritture finali S 4 = w 0 (x) r 1 (x) r 2 (x) w 2 (x) w 2 (z) leggeda = { ( r 1 (x), w 0 (x) ), ( r 2 (x), w 0 (x) )} scrittura finale di x = w 2 (x) scrittura finale di z = w 2 (z) S 5 V S 4 visto che non hanno la stessa relazione leggida S 6 è uno schedule seriale poiché le azioni di tutte le transazioni sono in sequenza quindi S 5 è view-serializzabile

16 View-equivalenza S 5 = w 0 (x) r 2 (x) w 2 (x) r 1 (x) w 2 (z)leggeda = { ( r 2 (x), w 0 (x) ), ( r 1 (x), w 2 (x) )} scrittura finale di x = w 2 (x) scrittura finale di z = w 2 (z) S 3 = w 0 (x) r 2 (x) r 1 (x) w 2 (x) w 2 (z) S 4 = w 0 (x) r 1 (x) r 2 (x) w 2 (x) w 2 (z) leggeda = { ( r 2 (x), w 0 (x) ), ( r 1 (x), w 0 (x) )} leggeda = { ( r 1 (x), w 0 (x) ), ( r 2 (x), w 0 (x) )} scrittura finale di x = w 2 (x) scrittura finale di z = w 2 (z) scrittura finale di x = w 2 (x) scrittura finale di z = w 2 (z)

17 View-equivalenza Lo schedule S corrisponde alla perdita di update e non è view serializzabile. Questo corrisponde ad una schedulazione delle transazioni in modo da non ottenere un esecuzione isolata. 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 S. S = r 1 (x) r 2 (x) w 1 (x) w 2 (x) S = r 1 (x) w 1 (x) r 2 (x) w 2 (x) S = r 2 (x) w 2 (x) r 1 (x) w 1 (x)

18 View-equivalenza Determinare la view-equivalenza di due schedule è un problema lineare: si determinano le due relazioni leggida e le scritture finali Per verificare che uno schedule è view-serializzabile è necessario confrontarlo con tutti i possibili schedule seriali ottenuti permutando le transazioni in esso contenuto. Determinare se uno schedule è view equivalente ad un qualsiasi schedule seriale è un problema NP-hard Si preferisce quindi una nozione di equivalenza più stretta che non copre tutti i casi, ma che abbia una complessità inferiore.

19 Conflict-equivalenza definizione di conflitto: Due azioni a i e a k si dicono in conflitto (i k) se entrambe operano sullo stesso oggetto ed almeno una di esse è una write r 2 (x) w 1 (x) è un conflitto lettura scrittura w 2 (x) w 1 (x) è un conflitto lettura scrittura r 2 (x) w 2 (x) non è un conflitto

20 Conflict-equivalenza Uno schedule S i è confilt-equivalente ad uno schedule S j ( S i c S k ) se presentano le stesse operazioni ed ogni coppia di operazioni in conflitto è nello stesso ordine in entrambi gli schedule. Uno schedule è confilct serializzabile se esiste uno schedule seriale ad esso conflict equivalente. CSR è linsieme di tutti gli schedule per cui esiste uno schedule seriale conflict equivalente.

21 Conflict-equivalenza CSR è strettamente contenuto in VSR. In altre parole esistono schedule che sono view serializzabili ma non sono conflict serializzabili. Tutti gli schedule in CSR sono in VSR Quindi la conflict-serializzabilità è una condizione sufficiente ma non necessaria per la view seriabilizzabilità.

22 Conflict-equivalenza Domande da porre: operano sullo stesso oggetto almeno una delle operazioni è di scrittura i diverso da j S 9 = w 0 (x) r 1 (x) w 0 (z) r 1 (z) r 2 (x) r 3 (z) w 3 (z) w 1 (x) S 10 = w 0 (x) w 0 (z) r 2 (x) r 1 (x) r 1 (z) w 1 (x) r 3 (z) w 3 (z)

23 Conflict-equivalenza Naturalmente enumerare in modo esaustivo tutti gli schedule seriali ripone lo stesso problema. E possibile determinare se uno schedule è conflict- serializzabile mediante il grafo dei conflitti. Ad ogni transazione dello schedule corrisponde un nodo del grafo S 9 = w 0 (x) r 1 (x) w 0 (z) r 1 (z) r 2 (x) r 3 (z) w 3 (z) w 1 (x) S 10 = w 0 (x) w 0 (z) r 2 (x) r 1 (x) r 1 (z) w 1 (x) r 3 (z) w 3 (z) T0T0 T1T1 T2T2 T3T3

24 Conflict-equivalenza E possibile determinare se uno schedule è conflict- serializzabile mediante il grafo dei conflitti. Ad ogni transazione dello schedule corrisponde un nodo del grafo Si traccia un arco fra i nodi Ti e Tk se esiste il conflitto ai ak e ai precede ak nello schedule S 9 = w 0 (x) r 1 (x) w 0 (z) r 1 (z) r 2 (x) r 3 (z) w 3 (z) w 1 (x) S 10 = w 0 (x) w 0 (z) r 2 (x) r 1 (x) r 1 (z) w 1 (x) r 3 (z) w 3 (z) T0T0 T1T1 T2T2 T3T3

25 Conflict-equivalenza E possibile determinare se uno schedule è conflict-serializzabile mediante il grafo dei conflitti. Ad ogni transazione dello schedule corrisponde un nodo del grafo Si traccia un arco fra i nodi Ti e Tk se esiste il conflitto ai ak e ai precede ak nello schedule Lo schedule è in CSR se e solo se il corrispondente grafo dei conflitti è aciclico S 9 = w 0 (x) r 1 (x) w 0 (z) r 1 (z) r 2 (x) r 3 (z) w 3 (z) w 1 (x) S 10 = w 0 (x) w 0 (z) r 2 (x) r 1 (x) r 1 (z) w 1 (x) r 3 (z) w 3 (z) T0T0 T1T1 T2T2 T3T3

26 Conflict-equivalenza Nonostante la linearità per determinare se uno schedule sia serializzabile o meno questa tecnica non viene applicata: il grafo risultante può essere di dimensioni notevoli La dinamicità vincola in alcuni casi a ricostruire il 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

27 Esercizio 1 Si consideri il seguente schedule, dove ogni operazione ri/wi si intende effettuata dalla transazione Ti: 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 legge-da e scrittura-finale.

28 Esercizio 1 r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) Dire che lo schedule è in VSR equivale a dimostrare che esiste un qualunque schedule seriale view-equivalente ad esso. La view-equivalenza è definita in terimini delle relazioni: Un operazione di lettura r i (x) leggeda w k (x) ( leggeda ( r i (x), w k (x) ) ) quando w k (x) precede r i (x) e non vi è nessun w n (x) compreso fra le due operazioni. Un operazione di scrittura w k (x) viene detta finale se è lultima scrittura sull oggetto x che appare nello schedule soluzione1: 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

29 Esercizio 1 r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) Soluzione 2: 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 leggeda contiene la coppia w1(r) r3(r) l ipotetico schedule seriale view-equivalente deve quindi avere elencate prima le operazioni delle transazioni T1 poi quelle di T3 per avere la stessa relazione leggeda. r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) ma la relazione T1 è lultima 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

30 Esercizio 2 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 lesercizio, specificando le relazioni legge-da e scrittura- finale.

31 Locking a due fasi Meccanismi che superano le limitazioni discusse: Locking a due fasi Timestamp Le operazioni di scrittura e lettura sono protette con lesecuzione di tre primitive: r_lock w_lock unlock

32 Locking a due fasi scheduler DB r_lock 1 (x) w_lock 1 (y) r_lock 2 (z) …… struttura dei dati Lo scheduler riceve una serie di richieste di queste primitive ne determina la correttezza attraverso lispezione di una struttura dati

33 Locking a due fasi scheduler DB r_lock 1 (x) r 1 (x) unlock 1 (x) …… struttura dei dati Vincoli sulle operazioni di read: r_lock 1 (x) r 1 (x) r_lock 2 (x) r 2 (x) unlock 2 (x) unlock 1 (x) r_lock 1 (x) r 1 (x)… ogni operazione di read è preceduta da un r_lock lr_lock deve essere seguito da un unlock il lock è condiviso perché su un dato possono essere attivi contemporaneamente più lock

34 Locking a due fasi scheduler DB w_lock 1 (x) w 1 (x) unlock 1 (x) …… struttura dei dati Vincoli sulle operazioni di write: w_lock 1 (x) w 1 (x) w_lock 2 (x) w 2 (x) unlock 2 (x) unlock 1 (x)w_lock 1 (x) w 1 (x)… ogni operazione di write è preceduta da un w_lock il w_lock deve essere seguito da un unlock il lock è esclusivo perché su un dato non possono essere attivi contemporaneamente più lock w_lock 1 (x) w 1 (x) unlock 1 (x) w_lock 2 (x) w 2 (x) unlock 2 (x)

35 Locking a due fasi Proprietà una transazione si dice ben formata quando rispetta le regole precedentemente illustrate loperazione di lock della risorsa può avvenire anche prima rispetto alleffettiva lettura e scrittura potremmo avere ununica operazione di lock che di fatto è un lock esclusivo in generale un lock esclusivo in scrittura consente anche la lettura o si può passare da un lock condiviso ad uno esclusivo.

36 Locking a due fasi 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.

37 Locking a due fasi La richiesta di lock è caratterizzata dalla transazione richiedente, e dalla risorsa richiesta. La politcha di decisione per la concessione dei lock e rappresentata nella tabella dei conflitti. richiesta Stato della risorsa X X liberaX concessa con r_lock X concessa con w_lock r_lock ( x )ok / r_lock ( x ) no / attesa w_lock ( x )ok / w_lock ( x )no / attesa unlockerrorok / dipendeok / libero

38 Locking a due fasi In generale, lo schedule ottenuto seguendo queste regole non è serializzabile. Occorre porre delle restrizioni sulle singole transizioni relative allordinamento della richiesta dei lock. Locking a due fasi ( 2PL ): una transazione dopo aver rilasciato un lock non può acquisirne altri.

39 Locking a due fasi Risorse richieste t Fase crescente Fase calante

40 Locking a due fasi Terema: Se il lock manager rispetta la politica definita nella tabella dei conflitti e le transazioni seguono il 2PL, genera schedule serializzabile. La classe 2PL contiene gli schedule che soddisfano queste condizioni.

41 Locking a due fasi Dim: Dimostriamo che la classe 2PL è strettamente contenuta nella classe CSR Se uno schedule è in 2PL allora è anche CSR Supponiamo che lo schedule sia in 2PL sia e non in CSR. S 2PL e S CSR. evidentemente esiste un ciclo t1 t2 t3 t4 t5 t6 ….. tn t1, t1 e t2 operano in modo conflittuale sulla stessa risorsa quindi t1 deve rilasciare la risorsa a t2 affinchè si possa procedere il conflitto tn t1 stabilisce che la transazione t1 deve attendere cha la transazione tn rilasci la risorsa prima di acquisirla Assurdo la transazione t1 non segue il 2PL.

42 Locking a due fasi Le classi 2PL e CSR non sono equivalenti ci sono schedule in CSR che non sono in 2PL. r1(x) w1(x) r2(x) w2(x) r3(y) w1(y) T1 T3 T2 Non è 2PL visto che la transazione T1 deve necessariamente rilasciare la risorsa x per T2 e richiedere un lock successivo per la risorsa y.

43 Locking a due fasi bot s=0 r_lock(y) read(y) s = y + s r_lock(z) read(z) s=s+z r_lock(x) read(x) s=s+x unlock(x) unlock(y) unlock(z) commit w_lock(x) w_lock(z) read(x) read(z) x=x+10 z=z-10 write(z) unlock(z) write(x) unlock(x) commit Tre oggetti x y z con definito il vincolo di integirtà x + y + z = 1000

44 Timestamp Semplice ma meno efficace del locking a due fasi Un timestamp è un evento che viene assiciato ad ogni operazione nel sistema. (ad esempio lorario) Il controllo mediante il metodo TS avviene nel seguente modo: Ad ogni transazione si associa un timestamp che rappresenta il momento di inizio si accetta uno schedule se e solo riflette lordinamento seriale delle transazioni in base al valore del timestamp di ciascuna transazione.

45 Timestamp Ad ogni oggetto x si associano due indicatori WTM(x): il ts della transazione con timestamp più grosso che ha eseguito lultima scrittura RTM(x): il ts della transazione con timestamp più grosso che ha eseguito lultima lettura 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.

46 Timestamp Politica dello scheduler read(x,ts): se ts < WTM(x) la transazione viene uccisa altrimenti è accettata, RTM(x) è posto al valore massimo fra RTM(x) e ts write(x,ts): se ts < WTM (x) o ts < RTM(x) la transazione viene uccisa altrimenti viene accettata. WTM(x) viene aggiornato con il valore di ts Ogni transazione non può leggere o scrivere un dato scritto da una transazione con timestamp superiore Non può scrivere un dato già letto da una transazione con timestamp superiore

47 Timestamp read(x,ts): se ts < WTM(x) la transazione viene uccisa altrimenti è accettata, RTM(x) è posto al valore massimo fra RTM(x) e ts write(x,ts): se ts < WTM (x) o ts < RTM(x) la transazione viene uccisa altrimenti viene accettata. WTM(x) viene aggiornato con il valore di ts RTM(x)=7 WTM(x)=5 richiesterispostevalori r(x,6)ok r(x,7)okRTM(x)=7 r(x,9)okRTM(x)=9 w(x,8)noT8 uccisa w(x,11)okWTM(x)=11 r(x,10)noT10 uccisa

48 Timestamp IL metodo TS uccide un elevato numero di transazioni. 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. w1(x) r2(x) r3(x) r4(x)r2(x) r3(x) r4(x) w1(x) La transazione t1 segnala lintenzione di effettuare una scrittura RTM (x)=0 WTM(x)=0 RTM (x)=4 WTM(x)=0 La transazione t1 viene uccisa visto che 1

49 Timestamp Utilizzo delle multiversioni: si mantengono diverse copie dello stesso oggetto una per ogni transazione che lo modifica. Ogni volta che una transazione genera una nuova copia delloggetto x, (la i-esima) viene creata una nuova copia WTMi(x). RTM(x) rimane globale

50 Timestamp Regole: r(x,ts): una lettura è sempre accettata, sia WTM i (x) lultima versione aggiornata di x se ts > i si legge WTM i (x) altrimenti si sceglie una versione k t.c. WTM k (x) < ts < WTM k+1 (x) w(x,ts): se ts < RTM si rifiuta la richiesta altrimenti si inserisce la i-esima copia WTMi(x)=ts

51 Timestamp Nei sistemi reali le copie che si mantengono sono al massimo 2. Questa tecnica introdotta per il metodo basato sui timestamp, viene poi utilizzata anche nel metodo di locking a due fasi.

52 Classi VSR CSR TS2PL

53 Classi La classe VSR include strettamente la classe CSR La classe CSR include strettamente la classi 2PL e TS 2PL e TS hanno intersezione non nulla ma non sono una inclusa nellaltra Dimostriamo che ci sono schedule che sono in TS ma non in 2PL Schedule che sono in 2PL ed in TS Schedule che sono in 2PL ma ma non in TS

54 Classi Il seguente schedule è in VSR? r1(x)w1(x)r2(x)r3(x)w2(y)r1(z)w3(z)r3(t)w3(t)r4(t)w4(y)w5(y) T1 T5 T3 T4 T2

55 Classi Consideriamo gli indici delle transazioni come il TS ad essi assegnato 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 è in TS Considerando ogni oggetto del DB ogni transazione opera nellordine indotto dal loro timestamp. Lo schedule è quindi inTS 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

56 Classi 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 non è in 2PL La transazione 1 legge loggetto x ed è poi costretta a rilasciarlo per la transazione2 Poi essa acquisisce nuovamente loggetto z. Abbiamo quindi uno schedule TS ma non 2PL

57 Classi r1(x)w1(x)r2(x)w2(x) questo schedule è sia in TS che in 2PL r2(x)w2(x)r1(x)w1(x) non è in TS in quanto la transazione con timestamp superiore legge successivamente x ma è in 2PL visto che le risorse vengono allocate in modo oridinato

58 Classi Nel 2PL le transazioni sono poste in attesa, nel TS uccise Nel 2PL lordine è imposto dai conflitti, nel TS dai timestamp Il 2PL può portare a blocchi critici Costa più il restart del TS rispetto allattesa del 2PL

59 Gestione dei Lock Il lock manager riceve le richieste di r_lock w_lock e un_lock caratterizzate dalle seguenti segnature: r_lock(T,x,errcod,timeout) w_lock(T,x,errcod,timeout) un_lock(T,x) Se la richiesta non può essere subito soddisfatta il processo viene messo in coda La probabilità di essere messi in coda (conflitti) è pari a: (numero di transazioni x oggetti medi richiesti) / oggetti totali Quando scatta il timeout una transazione può decidere: di effettuare un rollback e ripartire dallinizio richiedere nuovamente la risorsa conservando quelle acquisite

60 Gestione dei lock Struttura delle tabelle dei conflitti, per ogni oggetto del DB ci sono: tre bit per lo stato delloggetto un contatore per i processi in attesa

61 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 laccesso concorrente su tuple diverse aumentando i conflitti. Daltra 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

62 Lock gerarchico 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 DB Tab1 Tab2Tabn parte1 parte2 ……. tupla1 tupla2 …….

63 Lock gerarchico Primitive fornite dalla tecnica: XL: lock esclusivo. SL: lock condiviso. ISL: intenzione di bloccare uno dei figli del nodo attuale in modo condiviso. IXL: intenzione di bloccare uno dei figli del nodo attuale in modo esclusivo. SIXL: lock condiviso del nodo attuale e intenzione di bloccare in modo esclusivo uno dei figli. DB Tab1 Tab2Tabn parte1 parte2 ……. tupla1 tupla2 …….

64 Lock gerarchico Per richiedere in modo esclusivo una tupla occorrerà un IXL a livello di DB, Tab e parte. Una volta ottenuto quello della parte richiedere lXL a livello di tupla. Le risorse vengono sempre rilasciate in ordine inverso DB Tab1 Tab2Tabn parte1 parte2 ……. tupla1 tupla2 …….

65 Lock gerarchico Regole: Si richiedono i lock partendo dalla radice, scendendo verso lalbero Si rilasciano le risorse partendo da quella con granularità più bassa e risalendo lalbero. Per poter richiedere un SL o ISL su un nodo Si deve giè possedere un SIXL o IXL sul padre Per poter richiedere un IXL, XL o SIXL su un nodo, si deve già possedere un lock SIXL o IXL

66 Lock gerarchico DB Tab1 Tab2Tabn parte1 parte2 ……. tupla1 tupla2 ……. rischiest a Stato risorsa ISLIXLSLSIXLXLfree ISLOk NoOk IXLOk NonoNoOk SLOkNoOkNo Ok SIXLOkNo Ok XLNo no Ok

67 Livelli di lock in lettura Compromesso prestazioni correttezza Le soluzioni proposte garantiscono la correttezza ma possono degradare le performance del sistema Si preferisce rinunciare alla correttezza di letture a discapito delle performance Si definiscono tre livelli di consistenza in ordine crescente

68 Livelli di lock in lettura Committed read: si richiede che i Dati letti sianio quelli che effettivamente derivano da una commit della transazione. questo evita le letture sporche la perdita di update? Cursor stability: per acceddere ad intere tabelle la transazione viola il principio del 2PL. Effettuando il lock e lun_lock di una riga alla volta. Repeteable read: coincide col 2PL. A seconda della condizione si utilizza la strategia piu adeguata, ad esempio per transazioni bancarie si utilizza il terzo livello.

69 Blocco critico (deadlock) Un problema rilevante tipico dei sistemi concorrenti in cui si introducono attese. T1:r(x)w(y) T2:r(y)w(x) S: r_lock1(x) r_lock2(y) r1(x) r2(y) w_lock1(y) w_lock2(x) T1 attende che loggetto y sia liberato daT2 T2 attende che loggetto x sia liberato da T1

70 Blocco critico (deadlock) La probabilità che si verifiche un blocco critico è molto bassa Ci sono 3 tecniche per risolvere il blocco critico: timeout prevenzione rilevamento

71 Timeout Utilizzato nella maggior parte dei DBMS reali Una transazione viene tenuta un tempo limitato in attesa sulla risorsa Scaduta lattesa alla transazione viene data una risposta negativa per il lock richiesto In questo modo transazioni in deadlock vengono tolte dallattesa e forse abortite. Scelta del timeout alta: risolve tardi i deadlock basso: tende a rilevare come blocchi critici anche semplice attese sulle risorse. Si uccidono quindi transazioni che erano in semplice attesa sprecando lavoro e tempo.

72 Prevenzione dei blocchi critici Sol1: una tecnica prevede di dichiarare allinizio tutte le risorse che la transazione dovrà utilizzare (spesso non note allinizio) Sol2: Si acquisiscono timestamp e t i attende la risorsa acquisita da t j solo sotto determinate condizioni (es i < j): 50% delle transazioni che generano conflitto vengono messe in coda il restante uccise. per la scelta delle transizioni da uccidere distinguiamo tutte le politiche in: interrompenti: si uccide la transazione che detiene la risorsa non-interrompenti: la transazione viene uccisa solo allatto di fare una nova richiesta

73 Prevenzione dei blocchi critici Possiamo uccidere le transazioni che hanno fatto meno lavoro starvation: blocco individuale una transazione allinizio utilizza un oggetto su cui il conflitto e molto probabile. Avendo fatto poco lavoro viene uccisa ripetutamente. Per risolvere il problema una transazione non può essere uccisa ripetutamente Tecnica poco usata visto che per un ogni 2 conflitti si uccide mediamente una transazione e la probabilità del blocco critico è molto più bassa rispetto ad un conflitto.

74 Rilevamento dei deadlock Periodicamente si scorrono le tabelle di allocazione delle risorse alla ricerca di transazioni in deadlock Il rilevamento viene fatto analizzando le relazioni di attesa fra le varie transazioni determinando se esistono cicli.

75 Esercizio Dire se il seguente schedule w2(y)r1(z)w3(z)r3(t)w3(t)r4(t)w4(y)w5(y) r1(x)w1(x)r2(x)r3(x) è in VSR

76 Esercizio 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 lesercizio, specificando le relazioni legge-da e scrittura- finale.

77 Esercizio T1 = r1(x) r1(t) w1(r) w1(y) w1(t) legge x e t da T0 (stato iniziale), s.f. di y ed r T2 = r2(x) r2(v) w2(z) legge x da T3 e v da T0 s.f. di z T3 = r3(x) w3(x) r3(r) w3(t) w3(v) w3(t) legge x da T0 ed r da T1, s.f. x, t, v Innanzitutto si ha T3 < T2, perchè T2 legge x da T3. Ma si ha anche T2 < T3, perché T2 legge v da T0, e invece T3 scrive v. Dunque lo schedule non è VSR.

78 Esercizio Quali anomalie producono i seguenti schedule: r1(x) r2(x) w1(x) w2(x) perdita di udate r1(x) r1(y) r2(z) r2(y) w2(y) w2(z) r1(z) update fantasmi

79 Esercizio r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) 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

80 Esercizio Dire a quale situazione corrisponde lo schedule seguente, supponendo che tutti i lock richiesti vengano concessi: r_lock1(x), r_lock2(y), r_lock3(z), w_lock3(x), w_lock1(y) w_lock2(z)

81 Esercizio r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) 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

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

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

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

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

86 Esercizio r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) 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

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

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

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

90 Esercizio r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) 1 uccisa WTM(x)=0 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


Scaricare ppt "Tecnologia di un data base server: Controllo della Concorrenza Leonardo Mostarda Sea Lab."

Presentazioni simili


Annunci Google