BASI DI DATI DISTRIBUITE. Esercizio n. 1 Si consideri la base dati:

Transcript

1 BASI DI DATI DISTRIBUITE Esercizio n. 1 Si consideri la base dati: PRODUZIONE (NumeroSerie, TipoParte, Modello, Qta, Macchina) PRELIEVO (NumeroSerie, Lotto, Cliente, Venditore, Ammontare) CLIENTE (Nome, Città Indirizzo) VENDITORE (Nome, Città Indirizzo) Progettare la frammentazione orizzontale delle tabelle PRODUZIONE e PRELIEVO in base al tipo di parte (che assume quattro valori: Tastiera, Schermo, CPU e Cablaggio ), prevedendo quattro stabilimenti di produzione disposti a Milano, Torino, Roma e Napoli, e delle tabelle CLIENTE e VENDITORE in base a tre bacini di vendita, centrati su Torino, Milano e Roma; si supponga che le vendite siano distribuite per bacini geografici (quindi, clienti di Milano sono serviti solo da venditori di Milano; si assuma che il bacino di vendita di Roma comprenda anche Napoli) e che ciascuna area geografica abbia una propria base di dati (cioè che sia disponibile una base di dati a Milano, Torino, Roma e Napoli). Esprimere a livello di trasparenza di frammentazione, di allocazione e di linguaggio le interrogazioni: 1. Determinare la quantità disponibile del prodotto 77Y Determinare i clienti che hanno comprato qualche lotto dal rivenditore Bianchi, che ha ufficio a Roma. 3. Determinare le macchine utilizzate per la produzione dei pezzi di tipo Tastiera venduti al cliente Rossi. 4. Modificare l indirizzo del cliente Rossi, che si trasferisce da Via Po 45 di Milano a Viale Trastevere 150 di Roma 5. Calcolare la somma degli importi degli ordini ricevuti a Milano, Torino e Roma (si noti che anche le funzioni aggregate sono disponibili) Scrivere poi, ipotizzando di usare il DBMS di Milano, una richiesta remota, una transazione remota, una transazione distribuita e una richiesta distribuita. Esercizio n. 2 Descrivere come l'organizzazione di una riunione (di un insieme di persone che debbono essere tutte presenti) possa essere basata su un protocollo con le stesse caratteristiche del commit a due fasi. Esercizio n. 3 Si consideri il protocollo di commit a due fasi (2PC). 1. Spiegare perché: (a) un guasto del coordinatore (TM) può avere conseguenze molto pesanti anche sulle prestazioni dei partecipanti (RM); (b) un guasto di un partecipante non ha conseguenze particolari sulle prestazioni degli altri partecipanti 1

2 (a parte l eventuale abort di transazioni). Per ovviare alle conseguenze negative di un guasto del coordinatore, alcune implementazioni del 2PC prevedono la possibilità di comunicazione fra i partecipanti (mentre la versione base prevede solo comunicazione fra il coordinatore e ciascuno dei partecipanti). In particolare, un partecipante che abbia una transazione in stato di ready può chiedere agli altri partecipanti informazioni sullo stato di tale transazione (che può essere prima-del-ready, ready, commit o abort ) presso di loro. 2. In tale contesto indicare (a) come (e in quali casi) il partecipante può trarre profitto dalle risposte ottenute; (b) quali insiemi di risposte il partecipante può ricevere e quali invece no. Esercizio n. 4 Descrivere come si modifica il protocollo di ripresa a caldo tendo presente che alcune sottotransazioni distribuite possono essere in stato di ready. Esercizio n. 5 Applicare il protocollo di ripresa a caldo dopo la caduta di un nodo assumendo un algoritmo di commit a due fasi, a fronte del seguente input (ove r(ti) indica la presenza del record di ready): B(T1), B(T2), B(T3), I(T1,O1,A1), D(T2,O2,B2), B(T4), R(T1), U(T4,O3,B3,A3), C(T1), CK(T2,T3,T4), B(T5), B(T6), U(T5,O5,B5,A5), R(T5), B(T7), U(T7,O6,B6,A6), B(T8), U(T6,O1,B7,A7), A(T7), R(T6), guasto Esercizio n. 6 Descrivere un esempio di comportamento di una base di dati replicata che produce disallineamento tra i dati. Esercizio n. 7 Descrivere un esempio di replicazione simmetrica che produce inconsistenza dei dati. 2

3 SOLUZIONE Esercizio 1 Ia PARTE Frammentazione orizzontale della tabella PRODUZIONE (4 tabelle) PRODUZIONE _1 = σtipoparte= Tastiera (PRODUZIONE) PRODUZIONE _2= σtipoparte= Schermo (PRODUZIONE) PRODUZIONE _3= σtipoparte= CPU (PRODUZIONE) PRODUZIONE _4= σtipoparte= Cablaggio (PRODUZIONE) Frammentazione orizzontale (derivata) della tabella PRELIEVO (4 tabelle) PRELIEVO_1= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σtipoparte= Tastiera (PRELIEVO NumeroSerie = SN SN NumeroSerie (PRODUZIONE))) PRELIEVO_2= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σtipoparte= Schermo (PRELIEVO NumeroSerie = SN SN NumeroSerie (PRODUZIONE))) PRELIEVO_3= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σtipoparte= CPU (PRELIEVO NumeroSerie = SN SN NumeroSerie (PRODUZIONE))) PRELIEVO_4= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σtipoparte= Cablaggio (PRELIEVO NumeroSerie = SN SN NumeroSerie (PRODUZIONE))) Frammentazione orizzontale della tabella CLIENTE (3 tabelle) CLIENTE_1= σcittà = Torino (CLIENTE) CLIENTE_2= σcittà = Milano (CLIENTE) CLIENTE_3= σcittà = Roma V Città = Napoli (CLIENTE) Frammentazione orizzontale della tabella VENDITORE VENDITORE_1= σcittà = Torino (VENDITORE) VENDITORE _2= σcittà = Milano (VENDITORE) VENDITORE _3= σcittà = Roma V Città = Napoli (VENDITORE) Le tabelle PRODUZIONE_1, PRELIEVO_1, CLIENTE_1, VENDITORE_1 potranno essere allocate a Torino (Torino.Azienda.it) Le tabelle PRODUZIONE_2, PRELIEVO_2, CLIENTE_2, VENDITORE_2 potranno essere allocate a Milano (Milano.Azienda.it) Le tabelle PRODUZIONE_3, PRELIEVO_3, CLIENTE_3, VENDITORE_3 potranno essere allocate a Roma (Roma.Azienda.it) Le tabelle PRODUZIONE_4, PRELIEVO_4 potranno essere allocate a Napoli 3

4 (Napoli.Azienda.it) 4

5 Punto 1: Determinare la quantità disponibile del prodotto 77Y6878 Trasparenza di frammentazione: Procedure QueryDispo1 ( :Quan) from PRODUZIONE Trasparenza di allocazione: Procedure QueryDispo2 ( :Quan) from PRODUZIONE_1 from PRODUZIONE_2 from PRODUZIONE_3 from PRODUZIONE_4 Trasparenza di linguaggio: Procedure QueryDispo3 ( :Quan) from PRODUZIONE_1@Torino.Azienda.it from PRODUZIONE_2@Milano.Azienda.it from PRODUZIONE_3@Roma.Azienda.it from PRODUZIONE_4@Napoli.Azienda.it 5

6 Punto 2: Determinare i clienti che hanno comprato qualche lotto dal rivenditore Bianchi, che ha ufficio a Roma. Trasparenza di frammentazione: Procedure QueryLotto1 ( :Cl) from PRELIEVO Trasparenza di allocazione: Procedure QueryLotto2 ( :Cl) from PRELIEVO_1 from PRELIEVO_2 from PRELIEVO_3 from PRELIEVO_4 Trasparenza di linguaggio: Procedure QueryLotto3 ( :Cl) from PRELIEVO_1@Torino.Azienda.it from PRELIEVO_2@Milano.Azienda.it from PRELIEVO_3@Roma.Azienda.it from PRELIEVO_4@Napoli.Azienda.it 6

7 Punto 3: Determinare le macchine utilizzate per la produzione dei pezzi di tipo Tastiera venduti al cliente Rossi. Trasparenza di frammentazione: Procedure QueryMacchinePerTastiere1 ( :mac) select Macchine into :mac from PRODUZIONE join PRELIEVO On PRODUZIONE.NumeroSerie = PRELIEVO.NumeroSerie where Cliente = Rossi and TipoParte = Tastiera Trasparenza di allocazione: Procedure QueryMacchinePerTastiere2 ( :mac) select Macchine into :mac from PRODUZIONE_1 join PRELIEVO_1 On PRODUZIONE_1.NumeroSerie = PRELIEVO_1.NumeroSerie where Cliente = Rossi Trasparenza di linguaggio: Procedure QueryMacchinePerTastiere3 ( :mac) select Macchine into :mac from PRODUZIONE_1@Torino.Azienda.it join PRELIEVO_1@Torino.Azienda.it On PRODUZIONE_1.NumeroSerie =PRELIEVO_1.NumeroSerie where Cliente = Rossi Punto 4: Modificare l indirizzo del cliente Rossi, che si trasferisce da Via Po 45 di Milano a Viale Trastevere 150 di Roma Trasparenza di frammentazione: Procedure ModificaIndirizzo1 update CLIENTE set Indirizzo= Via Po 45, Città= Milano where Nome = Rossi Trasparenza di allocazione: Procedure ModificaIndirizzo2 7

8 delete from CLIENTE_3 where Nome = Rossi ; insert into CLIENTE_2 (Nome, Indirizzo, Città) values ( Rossi, Via Po 45, Milano ) Trasparenza di linguaggio: Procedure ModificaIndirizzo2 delete from CLIENTE_3@Roma.Azienda.it where Nome = Rossi ; insert into CLIENTE_2@Milano.Azienda.it (Nome, Indirizzo, Città) values ( Rossi, Via Po 45, Milano ) Punto 5: Calcolare la somma degli importi degli ordini ricevuti a Milano, Torino e Roma (si noti che anche le funzioni aggregate sono disponibili) Trasparenza di frammentazione: Procedure Ordini1 from PRELIEVO join VENDITORE on Venditore = Nome Trasparenza di allocazione: Procedure Ordini2 create view PRELIEVO as PRELIEVO_1 union PRELIEVO_2 union PRELIEVO_3 union PRELIEVO_4 from PRELIEVO join VENDITORE_1 on Venditore = Nome union from PRELIEVO join VENDITORE_2 on Venditore = Nome union from PRELIEVO join VENDITORE_3 on Venditore = Nome Trasparenza di linguaggio: Procedure Ordini2 create view PRELIEVO as PRELIEVO_1@Torino.Azienda.it union PRELIEVO_2@Milano.Azienda.it union 8

9 union from PRELIEVO join on Venditore = Nome union from PRELIEVO join VENDITORE_2@ Milano.Azienda.it on Venditore = Nome union from PRELIEVO join VENDITORE_3@Roma.Azienda.it on Venditore = Nome IIa PARTE Richiesta Remota select * from PRODUZIONE_2 where Qta > 100 Transazione Remota update CLIENTE_2 set Indirizzo = Via Fogazzaro 11 where Nome = Verdi Transazione Distribuita delete from CLIENTE_2 where Nome = Bianchi insert into CLIENTE_1 (Nome, Indirizzo, Città) values ( Bianchi, Via Ponente 45, Milano ) Richiesta Distribuita select Nome from PRELIEVO_1 join CLIENTE_3 on Cliente = Nome where NumeroSerie = 458X411 9

10 Soluzione Esercizio n.2 Un coordinatore contatta tutti i partecipanti che rispondono comunicando la propria disponibilità (in modo irrevocabile). Se le risposte sono ricevute tutte entro un tempo limite prefissato e sono tutte positive, allora il coordinatore fissa la riunione (altrimenti la disdice) comunicando la decisione a tutti i partecipanti. Soluzione Esercizio n.3 1(a) un guasto del coordinatore (TM) può avere conseguenze molto pesanti anche sulle prestazioni dei partecipanti (RM) perché questi ultimi potrebbero avere transazioni in stato di ready" (cioè nella finestra di incertezza"), con i lock acquisiti sulle risorse coinvolte, in attesa di risposta da parte del TM; 1(b) un guasto di un partecipante non ha conseguenze particolari sulle prestazioni degli altri partecipanti (a parte l'eventuale abort di transazioni), perché: - se il guasto avviene prima del ready, allora il partecipante stesso non risponde al prepare e quindi, scattato il time-out della prima fase, il coordinatore decide per l'abort; - se il guasto avviene dopo il ready, l'unica complicazione è la necessità di ripetere la seconda fase 2(a) se riceve almeno una risposta che contenga una decisione, può basarsi su di essa: se riceve almeno una risposta commit," può assumere che la transazione sia andata a buon fine, se riceve almeno una risposta abort," può assumere che essa sia fallita; 2(b) non è possibile che riceva abort" da un partecipante e commit" da un altro; né che riceva prima-del-ready" da uno e commit" da un altro. Soluzione Esercizio n.4 Protocollo di ripresa a caldo in sistemi distribuiti: 1) Si accede all ultimo blocco del log e si ripercorre il log all indietro fino al record di checkpoint. Si costruiscono 3 insiemi, detti di UNDO, di REDO e di READY. Gli insiemi REDO e READY sono vuoti, mentre quello di UNDO contiene le transazioni indicare nel record di checkpoint. 2) Si ripercorre il log in avanti, aggiungendo all insieme di UNDO tutte le transazioni di cui è presente il record di begin. Se viene rilevato un record ready, la corrispondente transazione viene spostata in READY. Se viene trovato un record di commit si sposta la transazione corrispondente nell insieme di REDO (viene rimossa da READY o da UNDO). Se si trova un record abort e la transazione corrispondente si trova in READY, essa viene tolta da READY e messa in UNDO. 3) Se l insieme READY non è vuoto, il sistema deve chiedere al TM (Transaction Manager) l esito delle transazioni di questo insieme, che si trovano in uno stato incerto. Il TM indica quali transazioni hanno effettuato il commit e quali l abort. Queste transazioni saranno quindi trasferite negli insiemi di REDO o di UNDO e i rispettivi record scritti nel log. 10

11 4) Il protocollo continua come in un sistema non distribuito. Soluzione Esercizio n.5 1) Il log viene ripercorso all indietro sino al record di checkpoint CK(T2,T3,T4) e si creano i tre insiemi di UNDO, REDO e READY. UNDO = { T2,T3,T4} REDO = {} READY = {} 2) Il record viene percorso in avanti, aggiornandogli insiemi. B(T5) UNDO = { T2,T3,T4,T5} REDO = {} READY = {} B(T6) UNDO = { T2,T3,T4,T5,T6} REDO = {} READY = {} R(T5) UNDO = { T2,T3,T4,T6} REDO = {} READY = {T5} B(T7) UNDO = { T2,T3,T4,T6,T7} REDO = {} READY = {T5} B(T8) UNDO = { T2,T3,T4,T6,T7,T8} REDO = {} READY = {T5} A(T7) UNDO = { T2,T3,T4,T6,T7,T8} REDO = {} READY = {T5} R(T6) UNDO = { T2,T3,T4 T7,T8} REDO = {} READY = {T5,T6} 3) A questo punto dovremmo chiedere al Transaction Manager l esito delle transazioni in stato di READY. Supponendo che il TM indichi un global commit per T5 e T6 otteniamo: UNDO = { T2,T3,T4, T7,T8} REDO = {T5,T6} I record C(T5) e C(T6) sono scritti nel log. 4) Il record viene ripercorso all indietro sino a D(T2,O2,B2), eseguendo le operazioni di UNDO. O6 = B6 O3 = B3 Insert O2 = B2 5) Infine il log viene percorso in avanti e vengono eseguite le operazioni di REDO. O5 = A5 O1 = A7 Soluzione esercizio n.6 Con riferimento allo schema data base descritto nell' Esercizio 1., supponiamo che ciascun frammento della tabella PRODUZIONE sia allocata a tutti i DBMS. Ciascun DBMS usa solo 11

12 un frammento e trasmette tutte le variazioni di questo frammento agli altri DBMS In questa maniera tutti i DBMS posseggono un intera copia del database. Nel caso di guasto di uno dei DBMS il Database è ancora completamente accessibile dagli altri sistemi:se tutte le query sono correttamente re-dirette, il guasto è trasparente al Cliente del Database. Tuttavia se si verifica un guasto della rete, questo può generare una partizione della rete, per esempio con due sottoreti indipendenti.in questa situazione è possibile un'inconsistenza dei dati : supponiamo che la tabella PRODUZIONE contiene una ennupla: NumeroSerie TipoParte Modello Qta Macchina CPU Pentium II 1000 A se due transazioni volessero entrambe sottrarre 800 dalla quantità di questa parte, una delle transazioni (la seconda in ordine temporale) fallirebbe, ma se le due transazioni sono presenti i due differenti DBMS che non sono connessi, essi non falliranno ma produrranno un'inconsistenza nel data base completo. Soluzione esercizio n.7 Se nel contesto di una replicazione simmetrica, ciascun DBMS ha una copia dell'intero DATABASE e può accedere ad essa completamente, allora le copie sono riconciliate. Questa situazione può produrre lo stesso effetto di un singolo database senza il controllo di concorrenza. Le due transazioni descritte nell' esercizio 4 possono produrre una inconsistenza anche senza un guasto di rete se le variazioni non sono comunicate immediatamente alle altre copie. 12