1- AFFIDABILITA. Esercizio n.1

Transcript

1 1- AFFIDABILITA Esercizio n.1 Il check-point prevede le seguenti attività (durante le quali non sono ammessi commit e abort): 1. scrittura in memoria stabile (force) di tutte le pagine "sporche" del buffer di transazioni che hanno già fatto il commit; 2. scrittura in memoria stabile (force) di tutti i record del log incluso il record di checkpoint (con la lista delle transazioni attive) Spiegare perchè il checkpoint sarebbe inutilizzabile se le operazioni avvenissero in ordine inverso (prima la scrittura del record di checkpoint e poi la force del buffer). Esercizio n.2 Illustrare brevemente una procedura di recovery (semplificata rispetto a quella usuale) utilizzabile nell'ipotesi che il protocollo di scrittura preveda che le scritture nella base di dati avvengano tutte dopo il commit. Spiegare perchè questa opportunità, pur permettendo una procedura di recovery più semplice ed efficiente, non viene molto utilizzata in pratica. Esercizio n.3 Descrivere la ripresa a caldo, indicando la costituzione progressiva degli insiemi di UNDO e REDO e le azioni di recovery, al fronte del seguente input: 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), A(T7), guasto Esercizio n.4 Con riferimento alla situazione di cui sopra, si supponga un guasto di dispositivo che involva gli oggetti O1,O2,O3. Si descriva la ripresa a freddo.

2 AFFIDABILITA (RISPOSTE) Risposta esercizio n.1 Se la flush avvenisse dopo la force del checkpoint, un eventuale guasto fra le due operazioni potrebbe rendere impreciso (e quindi inutilizzabile) il checkpoint: transazioni non indicate come attive potrebbero non aver svolto tutte le operazioni di scrittura in memoria secondaria. Risposta esercizio n.2 E sufficiente prevedere solo redo: poichè prima del commit non ci sono scritture, non ci sono operazioni da annullare per transazioni non andate a buon fine. Questa procedura non viene molto utilizzata in pratica perchè, pur più efficiente nel recovery, è complessivamente meno efficiente di una in cui il gestore del buffer può decidere liberamente quando scrivere in memoria secondaria. Si preferisce cioè una gestione ordinaria più efficiente rispetto ad una gestione più semplice dei guasti, poichè si assume che i guasti siano abbastanza rari. Risposta esercizio n.3 1) Prima di tutto si percorre indietro il log fino al primo record di check-point: CK(T1, T4, T5, T6). I due insiemi UNDO and REDO sono rispettivamente: UNDO= { T1, T4, T5, T6 } REDO={} 2) Si ripercorre in avanti il log e si aggiornano gli insiemi di UNDO e di REDO: - B(T7) UNDO= { T1, T4, T5, T6, T7 } REDO={} - A(T4) UNDO= { T1, T4, T5, T6, T7 } REDO={} - B(T8) UNDO= { T1, T4, T5, T6, T7, T8 } REDO={} - A(T7) UNDO= { T1, T4, T5, T6, T7,T8} REDO={} 3) Successivamente si ripercorre indietro il log fino all'azione I(T1, O1, A1), eseguendo le seguenti operazioni di Undo. O3=B7 O6=B6 O5=B5 O4=B4 O3=B3 Delete O1 4) Il log viene percorso in avanti, ma il set di REDO è vuoto, pertanto non verrà eseguita alcuna operazione di REDO. Risposta all'esercizio n.4 1)Si accede al dump; e al record dump del log. 2) Si percorre il log in avanti rifacendo tutte le azioni sulla parte deteriorata: Insert O1=A1 Delete O2 O3=A3 Commit (T2) Abort (T4) O3=A7 3) è applicata la ripresa a caldo.

3 2-CONCORRENZA Esercizio n.1 Le seguenti situazioni corrispondono ad alcune delle note anomalie delle transazioni concorrenti. Commentare brevemente ciascuna di esse e spiegare come il 2PL (con le sue estensioni) riesce ad evitarle. 1. Un cliente consulta un calendario di concerti e ne individua uno che gli interessa. Quando chiede il biglietto gli viene detto che il calendario non era definitivo e quel concerto non esiste. 2. Un signore ha dieci milioni sul proprio conto corrente e firma due assegni da tre milioni ciascuno. I due beneficiari si presentano quasi contemporaneamente a due impiegati diversi della stessa banca, ciascuno dei quali verifica che i soldi sono disponibili (ci sono dieci milioni) e, pagato l'assegno, registra il nuovo saldo di sette milioni. 3. Un appassionato lettore di gialli chiede quali libri siano disponibili di Agatha Christie. In risposta, riceve un elenco di tre libri. Chiede di ordinarli tutti. Quando li riceve, sono quattro. Esercizio n.2 Un'applicazione di una compagnia aerea prevede molte transazioni come la seguente, in cui x denota il numero di posti disponibili su un certo volo e y il numero di posti che vengono prenotati, su tale volo, con la transazione stessa: read(x) x:= x - y write(x) Con riferimento a tale contesto: 1. Indicare quale tipo di anomalia potrebbe nascere, in assenza di controllo di concorrenza; mostrare uno schedule con tale anomalia. 2. Mostrare come il 2PL impedisca l'anomalia, commentando anche i vantaggi e svantaggi che si avrebbero nei due casi seguenti (a) vengono utilizzati inizialmente lock condivisi, che vengono poi "promossi" a lock esclusivi; (b) vengono utilizzati sin dall'inizio lock esclusivi. Esercizio n.3 Con riferimento allo schedule seguente che denota un anomalia di aggiornamento fantasma (gost update ) eliminarla utilizzando il 2PL stretto usando, ove richiesto, subito lock esclusivi.

4 t1 bot r1(x) r1(y) r1(z) s =x+ y + z commit t2 bot r2(y) y = y r2(z) z = z w2(y) w2(z) commit Esercizio n.4 Se gli schedule seguenti si presentassero a uno scheduler che usa il locking a due fasi, quali transazioni verrebbero messe in attesa? Si noti che, una volta posta in attesa una transazione, le sue successive azioni non vanno più considerate. 1. r1(x), w1(x), r2(z), r1(y), w1(y), r2(x), w2(x), w2(z) 2. r1(x), w1(x), w3(x), r2(y), r3(y), w3(y), w1(y), r2(x) 3. r1(x), r2(x), w2(x), r2(x), r4(z), w1(x), w3(y), w3(x), w1(y), w5(x), w1(z), w5(y), r5(z) 4. r1(x), r3(y), w1(y), w4(x), w1(t), w5(x), r2(z), r3(z), w2(z), w5(z), r4(t), r5(t) 5. r1(x), r2(x), w2(x), r3(x), r4(z), w1(x), r3(y), r3(x), w1(y), w5(x), w1(z), r5(y), r5(z) 6. r1(x), r1(t), r3(z), r4(z), w2(z), r4(x), r3(x), w4(x), w4(y), w3(y), w1(y), w2(t) 7. r2(x), r4(x), w4(x), r1(y), r4(z), w4(z), w3(y), w3(z), w1(t), w2(z), w2(t) Esercizio n. 5 Se gli schedule seguenti si presentassero a uno scheduler basato su timestamp, quali transazioni verrebbero abortite? 1. r1(x), w1(x), r2(z), r1(y), w1(y), r2(x), w2(x), w2(z) 2. r1(x), w1(x), w3(x), r2(y), r3(y), w3(y), w1(y), r2(x) 3. r1(x), r2(x), w2(x), r2(x), r4(z), w1(x), w3(y), w3(x), w1(y), w5(x), w1(z), w5(y), r5(z) 4. r1(x), r3(y), w1(y), w4(x), w1(t), w5(x), r2(z), r3(z), w2(z), w5(z), r4(t), r5(t) 5. r1(x), r2(x), w2(x), r3(x), r4(z), w1(x), r3(y), r3(x), w1(y), w5(x), w1(z), r5(y), r5(z) 6. r1(x), r1(t), r3(z), r4(z), w2(z), r4(x), r3(x), w4(x), w4(y), w3(y), w1(y), w2(t) 7. r2(x), r4(x), w4(x), r1(y), r4(z), w4(z), w3(y), w3(z), w1(t), w2(z), w2(t) Esercizio 2.6 Si consideri un oggetto X sul quale opera un controller di concorrenza basato su timestamp, con WTM(X) = 5, RTM(X) = 7. Indicare le azioni dello scheduler a fronte del seguente input nel caso mono-versione e in quello multi-versione: r(x,8), r(x,17), r(x,16), w(x,18), w(x,23), w(x,29), r(x,20), r(x,30), r(x,25)

5 CONCORRENZA (RISPOSTE) Risposte esercizio n.1 1. Questo potrebbe essere assimilato ad un caso di lettura sporca (il calendario non era denititivo non c'era stato un commit). Da un altro punto di vista, lo si poteva vedere come un caso di lettura inconsistente. Il 2PL stretto risolve comunque entrambi. 2. Un classico caso di perdita di aggiornamento, superabile con il 2PL. 3. In questo caso, il problema non è nel numero di libri, ma nel fatto che viene inserito un nuovo record, relativamente al quale i lock sui tre record preesistenti non hanno effetto; qui solo un lock sul predicato" può risultare efficace: si deve impedire che vengano inseriti ulteriori libri di Agatha Christie. Risposta all esercizio n.2 1. L'anomalia è di tipo lost update"; esempio di schedule (il volo deve essere lo stesso, il numero di posti sarà in generale diverso (quindi si usa lo stesso x e due diversi y1 e y2): N Ti Tj Valore di x 1 read(x) x0 2 read(x) x0 3 x:=x - y1 x0 4 write(x) x0-y1 5 x:= x-y2 x0-y1 6 write(x) x0-y2 Tabella 1 1. Il controllo di concorrenza basato su timestamp, alla riga 4, rileva che la transazione Ti (che assumiamo meno giovane di Tj) vuole scrivere un dato già letto da una transazione più giovane. Pertanto, Ti viene uccisa. 2. Attraverso l'emissione di richieste di lock e le regole che governano i lock stessi, le azioni vengono riordinate: N Ti Tj Lock manager Stato di x Valore di x 1 writelock(x) x0 2 writelockok (Ti,x) w -locked(ti) x0 3 read(x) w -locked(ti) x0 4 writelock(x) w -locked(ti) x0 5 wait(tj,x) w -locked(ti) x0 6 x=x-y1 w -locked(ti) x0 7 write(x) w -locked(ti) x0-y1 8 commit w -locked(ti) x0-y1 9 unlock(x) libera x0-y1 10 writelockok (Tj,x) w-locked(tj) x0-y1 11 read(x) w -locked(tj) x0-y1 12 x=x-y2 w-locked(tj) x0-y1 13 write(x) w -locked(tj) x0-y1-y2 14 commit w -locked(tj) x0-y1-y2 15 unlock(x) libera x0-y1-y2 TABELLA 2 Nell'esempio, sono stati utilizzati solo lock in scrittura (caso (b)). Con lock in lettura, da promuovere, si sarebbero potuti avere deadlock. In generale, la scelta (a) è più efficiente (ad esempio, se ci sono altre operazioni di sola lettura, esse possono procedere, almeno nella prima fase), ma presenta il rischio dello stallo, che invece non si corre nel caso (b).

6 Risposta esercizio n.3 N T1 T2 Lock manager Stato di x Stato di y Stato di z 1 bot free free free 2 r_lock(x) free free free 3 r_lockok (T1,x) r -locked(t1) free free 4 read(x) r -locked(t1) free free 5 bot r -locked(t1) free free 6 w_lock(y) r -locked(t1) free free 7 w_lockok (T2,y) r -locked(t1) w-locked(t2) free 8 read(y) r -locked(t1) w-locked(t2) free 9 r_lock(y) r -locked(t1) w-locked(t2) free 9 wait(t1,y) r -locked(t1) w-locked(t2) free 10 y=y-100 r -locked(t1) w-locked(t2) free 11 w_lock(z) r -locked(t1) w-locked(t2) free 12 w_lockok(t2,z) r -locked(t1) w-locked(t2) w_locked(t2) 13 read(z) r -locked(t1) w-locked(t2) w_locked(t2) 14 z=z+100 r -locked(t1) w-locked(t2) w_locked(t2) 15 write(y) r -locked(t1) w-locked(t2) w_locked(t2) 16 write(z) r -locked(t1) w-locked(t2) w_locked(t2) 17 commit r -locked(t1) w-locked(t2) w_locked(t2) 18 unlock(y) r -locked(t1) free w_locked(t2) 19 r_lockok (T1,y) r -locked(t1) r_locked(t1) w_locked(t2) 20 read(y) r -locked(t1) r_locked(t1) w_locked(t2) 21 r_lock(z) r -locked(t1) r_locked(t1) w_locked(t2) 22 wait(t1,z) r -locked(t1) r_locked(t1) w_locked(t2) 23 unlock(z) r -locked(t1) r_locked(t1) free 24 r-lockok(t1,z) r -locked(t1) r_locked(t1) r_locked(t1) 25 read(z) r -locked(t1) r_locked(t1) r_locked(t1) 26 eot r -locked(t1) r_locked(t1) r_locked(t1) 27 s=x+y+z r -locked(t1) r_locked(t1) r_locked(t1) 28 commit r -locked(t1) r_locked(t1) r_locked(t1) 29 unlock(x) free r_locked(t1) r_locked(t1) 30 unlock(y) free free) r_locked(t1) 31 unlock(z) free free) free 32 eot Risposta esercizio n.4 1) r1(x), w1(x), r2(z), r1(y), w1(y), r2(x), w2(x), w2(z) Nessuna transazione in attesa 2) r1(x), w1(x), w3(x), r2(y), r3(y), w3(y), w1(y), r2(x) Le transazioni 3 e 1 e poi 2 vengono messe in attesa, producendo una situazione di deadlock; infatti, l azione r2(x) deve aspettare l oggetto x, messo in lock dalla transazione 1, e la transazione 1 è in attesa su w1(y) dell oggetto y, messo in lock dalla transazione 2. 3) r1(x), r2(x), w2(x), r3(x), r4(z), w1(x), w3(y), w3(x), w1(y), w5(x), w1(z), w5(y), r5(z) Le transazioni 2, 1, 3 e 5 sono messe in attesa a causa del lock in lettura su x. Si crea una situazione di deadlock dovuta alla richiesta di lock in scrittura su x da parte delle transazioni 1 e 2, entrambe con un lock in lettura sulla stessa risorsa x. 4) r1(x), r3(y), w1(y), w4(x), w1(t), w5(x), r2(z), r3(z), w2(z), w5(z), r4(t), r5(t)

7 Le transazioni 1, 4, 5 e 2 sono in attesa. La transazione 1 deve aspettare per y (allocato da t3), le transazioni 4 e 5 devono aspettare per x (allocato da t1) e la transazione 2 deve aspettare per z (allocato da t3). 5) r1(x), r2(x), w2(x), r3(x), r4(z), w1(x), r3(y), r3(x), w1(y), w5(x), w1(z), r5(y), r5(z) Le transazioni 2, 1 e 5 sono in attesa. Devono aspettare per x (allocata da t1, t2 e t3) 6) r1(x), r1(t), r3(z), r4(z), w2(z), r4(x), r3(x), w4(x), w4(y), w3(y), w1(y), w2(t) Le transazioni 2, 3 e 4 vengono messe in attesa. t2 e t4 devono aspettare per z (allocata da t3) e t3 deve aspettare per y (allocata da t1) 7) r1(x), r4(x), w4(x), r1(y), r4(z), w4(z), w3(y), w3(z), w1(t), w2(z), w2(t) Assumendo che t1 rilasci il lock esclusivo su t al termine delle sue operazioni, le transazioni 3 e 4 sono in attesa. Devono aspettare per x e y, allocate da t1. Risposta esercizio n.5 1) r1(x), w1(x), r2(z), r1(y), w1(y), r2(x), w2(x), w2(z) write(x,1) Ok WTM(x)=1 read(z,1) Ok RTM(z)=1 read(y,1) Ok RTM(y)=1 write(y,1) Ok WTM(y)=1 read(x,2) Ok RTM(x)=2 write(z,2) Ok WTM(z)=2 Non viene abortita nessuna transazione. 2) r1(x), w1(x), w3(x), r2(y), r3(y), w3(y), w1(y), r2(x) write(x,1) Ok WTM(x)=1 write(x,3) Ok WTM(x)=3 read(y,2) Ok RTM(y)=2 read(y,3) Ok RTM(y)=3 write(y,3) Ok WTM(y)=3 write(y,1) t1 aborted read(x,2) t2 aborted 3) r1(x), r2(x), w2(x), r3(x), r4(z), w1(x), w3(y), w3(x), w1(y), w5(x), w1(z), w5(y), r5(z) read(x,2) Ok RTM(x)=2 write(x,2) Ok WTM(x)=2 read(x,3) Ok RTM(x)=3 read(z,4) Ok RTM(z)=4 write(x,1) t1 aborted write(y,3) Ok WTM(y)=3 write(x,5) Ok WTM(x)=5 write(y,5) Ok WTM(y)=5 read(z,5) Ok RTM(z)=5

8 4) r1(x), r3(y), w1(y), w4(x), w1(t), w5(x), r2(z), r3(z), w2(z), w5(z), r4(t), r5(t) read(y,3) Ok RTM(y)=3 write(y,1) t1 aborted write(x,4) Ok WTM(x)=4 write(x,5) Ok WTM(x)=5 read(z,2) Ok RTM(z)=2 read(z,3) Ok RTM(z)=3 write(z,2) t2 aborted write(z,5) Ok WTM(z)=5 read(t,4) Ok RTM(t)=4 read(t,5) Ok RTM(t)=5 5) r1(x), r2(x), w2(x), r3(x), r4(z), w1(x), r3(y), r3(x), w1(y), w5(x), w1(z), r5(y), r5(z) read(x,2) Ok RTM(x)=2 write(x,2) Ok WTM(x)=2 read(x,3) Ok RTM(x)=3 read(z,4) Ok RTM(z)=4 write(x,1) t1 aborted read(y,3) Ok RTM(y)=3 read(x,3) Ok RTM(x)=3 write(x,5) Ok WTM(x)=5 read(y,5) Ok RTM(y)=5 read(z,5) Ok RTM(z)=5 6) r1(x), r1(t), r3(z), r4(z), w2(z), r4(x), r3(x), w4(x), w4(y), w3(y), w1(y), w2(t) read(t,1) Ok RTM(t)=1 read(z,3) Ok RTM(z)=3 read(z,4) Ok RTM(z)=4 write(z,2) t2 aborted read(x,4) Ok RTM(x)=4 read(x,3) Ok RTM(x)=4 write(x,4) Ok WTM(x)=4 write(y,4) Ok WTM(y)=4 write(y,3) t3 aborted write(y,1) t1 aborted 7) r1(x), r4(x), w4(x), r1(y), r4(z), w4(z), w3(y), w3(z), w1(t), w2(z), w2(t)

9 read(x,4) Ok RTM(x)=4 write(x,4) Ok WTM(x)=4 read(y,1) Ok RTM(y)=1 read(z,4) Ok RTM(z)=4 write(z,4) Ok WTM(z)=4 write(y,3) Ok WTM(y)=3 write(z,3) t3 aborted write(t,1) Ok WTM(t)=1 write(z,2) t2 aborted Risposta esercizio n.6 Mono-versione: RTM(x)=7 WTM(x)=5 read(x,8) Ok RTM(x)=8 read(x,17) Ok RTM(x)=17 read(x, 16) Ok RTM(x)=17 write(x,18) Ok WTM(x)=18 write(x,23) Ok WTM(x)=23 write(x,29) Ok WTM(x)=29 read(x,20) t20 aborted read(x,30) Ok RTM(x)=30 read(x,25) t25 aborted Multi-versione: RTM(x)=7 WTM1(x)=5 read(x,8) Ok RTM(x)=8 read(x,17) Ok RTM(x)=17 read(x, 16) Ok RTM(x)=17 write(x,18) Ok WTM2(x)=18 write(x,23) Ok WTM3(x)=23 write(x,29) Ok WTM4(x)=29 read(x,20) Ok RTM(x)=20 reads from x2 read(x,30) Ok RTM(x)=30 reads from x4 read(x,25) Ok RTM(x)=30 reads from x3