BDE-ARC 1 BDE Architetture distribuite

BDE-ARC 2 BDE Basi di dati distribuite a RETE : LAN (Local Area Network) LAN (Local Area Network) WAN (Wide Area Network) WAN (Wide Area Network) SYBASEORACLEDB2 CLIENT b DBMS : Sistema omogeneo Sistema omogeneo Sistema eterogeneo Sistema eterogeneo

BDE-ARC 3 BDE Problemi delle basi di dati distribuite Autonomia vs cooperazioneAutonomia vs cooperazione TrasparenzaTrasparenza EfficienzaEfficienza AffidabilitàAffidabilità

BDE-ARC 4 BDE Autonomia e cooperazione L'esigenza di autonomia: - Portare competenze e controllo laddove vengono gestiti i dati laddove vengono gestiti i dati - Rendere la maggior parte delle applicazioni NON distribuite (!) applicazioni NON distribuite (!) L'esigenza di cooperazione: - Alcune applicazioni sono intrinsecamente distribuite e richiedono l'accesso a distribuite e richiedono l'accesso a piu' basi di dati piu' basi di dati

BDE-ARC 5 BDE Frammentazione dei dati Scomposizione delle tabelle in modo da consentire la loro distribuzione proprieta': - Completezza - Completezza - Ricostruibilita' - Ricostruibilita'

BDE-ARC 6 BDE Frammentazione orizzontale FRAMMENTI: insiemi di tuple insiemi di tuple FR1 FR2 FR3 COMPLETEZZA: presenza presenza di tutte le tuple di tutte le tuple RICOSTRUZIONE: unione unione

BDE-ARC 7 BDE Frammentazione verticale FRAMMENTI: insiemi di attributi insiemi di attributi COMPLETEZZA: presenza presenza di tutti gli attributi di tutti gli attributi RICOSTRUZIONE: join sulla chiave join sulla chiave FR1 FR2 FR3

BDE-ARC 8 BDE Esempio: conti correnti bancari CONTO-CORRENTE (NUM-CC,NOME,FILIALE,SALDO) TRANSAZIONE (NPROG, NUM-CC,DATA, OPERAZIONE, AMMONTARE, CAUSALE) CENTRO FILIALE1FILIALE2 FILIALE3

BDE-ARC 9 BDE Frammentazione orizzontale principale  Pi R Ri =  Pi R esempio:  Filiale=1 CONTO-CORRENTE CONTO1 =  Filiale=1 CONTO-CORRENTE  Filiale=2 CONTO-CORRENTE CONTO2 =  Filiale=2 CONTO-CORRENTE  Filiale=3 CONTO-CORRENTE CONTO3 =  Filiale=3 CONTO-CORRENTE

BDE-ARC 10 BDE Frammentazione orizzontale derivata Si = S   Ri esempio: TRANS1 = TRANSAZIONE   CONTO1 TRANS2 = TRANSAZIONE   CONTO2 TRANS3 = TRANSAZIONE   CONTO3

BDE-ARC 11 BDE Allocazione dei frammenti CONTO1 CONTO2 CONTO3 TRANS1 TRANS2 TRANS3CENTROCONTO1 TRANS1 FILIALE 1 CONTO2 TRANS2 FILIALE 2 CONTO3 TRANS3 FILIALE 3

BDE-ARC 12 BDE Livelli di trasparenza Modalita’ per esprimere interrogazioni offerte dai DBMS commerciali: LIVELLI: FRAMMENTAZIONE ALLOCAZIONELINGUAGGIO

BDE-ARC 13 BDE Trasparenza di frammentazione SELECT SALDO SELECT SALDO FROM CONTO-CORRENTE FROM CONTO-CORRENTE WHERE NUM-CC=45 WHERE NUM-CC=45 QUERY : estrarre il saldo del conto corrente 45

BDE-ARC 14 BDE Trasparenza di allocazione SELECT SALDO FROM CONTO1 WHERE NUM-CC=45 WHERE NUM-CC=45 IF (NOT FOUND) THEN ( SELECT SALDO FROM CONTO2 WHERE NUM-CC=45 WHERE NUM-CC=45 UNION UNION SELECT SALDO FROM CONTO3 SELECT SALDO FROM CONTO3 WHERE NUM-CC=45 ) WHERE NUM-CC=45 ) IPOTESI : Allocazione incerta, probabilmente alla filiale 1

BDE-ARC 15 BDE Trasparenza di linguaggio SELECT SALDO FROM WHERE NUM-CC=45 WHERE NUM-CC=45 IF (NOT FOUND) THEN ( SELECT SALDO FROM WHERE NUM-CC=45 WHERE NUM-CC=45 UNION UNION SELECT SALDO FROM SELECT SALDO FROM WHERE NUM-CC=45 ) WHERE NUM-CC=45 )

BDE-ARC 16 BDEEfficienza Ottimizzazione delle query Modalita' di esecuzione - seriale - parallela

BDE-ARC 17 BDE Esecuzione seriale CONTO2 CONTO3CENTROCONTO1 FILIALE1 CLIENT

BDE-ARC 18 BDE Esecuzione parallela CLIENTCONTO1 FILIALE1 CONTO3 FILIALE3 CONTO2 FILIALE2

BDE-ARC 19 BDE Protocolli di commit

BDE-ARC 20 BDE Transazioni distribuite BEGIN TRANSACTION UPDATE UPDATE SET SALDO=SALDO SET SALDO=SALDO WHERE NUM-CC=45; WHERE NUM-CC=45; UPDATE UPDATE SET SALDO=SALDO SET SALDO=SALDO WHERE NUM-CC=35; WHERE NUM-CC=35;COMMIT-WORK END TRANSACTION

BDE-ARC 21 BDE Transazioni distribuite CLIENTFILIALE FILIALE

BDE-ARC 22 BDE Proprieta ' ACIDe dell’esecuzione distribuita Isolamento se ciascuna sottotransazione e' a due fasi la transazione e' globalmente serializzabile Consistenza se ciascuna sottotransazione preserva l'integrita' locale i dati sono globalmente consistenti Persistenza se ciascuna sottotransazione gestisce correttamente i log, i dati sono globalmente persistenti Atomicita' e' il principale problema delle transazioni distribuite

BDE-ARC 23 BDE Guasti in un sistema distribuito Caduta di nodiCaduta di nodi MSG Perdita di messaggiPerdita di messaggi Interruzione della reteInterruzione della rete

BDE-ARC 24 BDE Protocolli distribuiti e perdita di messaggi A: SEND(B,MSG) B: RECEIVE(MSG) SEND(A,ACK) A: RECEIVE(ACK)

BDE-ARC 25 BDE Commit a due fasi Protocollo per garantire l'atomicita' di sotto-transazioni distribuite Come un matrimonio - fase uno: dichiarazione di intenti - fase uno: dichiarazione di intenti - fase due: dichiarazione del matrimonio - fase due: dichiarazione del matrimonio Protagonisti - un coordinatore (Transaction Manager, TM) - un coordinatore (Transaction Manager, TM) - molti partecipanti (Resource Manager, RM) - molti partecipanti (Resource Manager, RM)

BDE-ARC 26 BDE Record nel log del coordinatore a PREPARE: identita' dei partecipanti b GLOBAL COMMIT/ABORT: decisione c COMPLETE: termine del protocollo Record nel log del partecipante a READY: disponibilita' al commit b LOCAL COMMIT/ABORT: decisione ricevuta

BDE-ARC 27 BDE Fase 1 C: WRITE-LOG(PREPARE) SET TIME-OUT SET TIME-OUT SEND (Pi,PREPARE) SEND (Pi,PREPARE) Pi: RECEIVE(C,PREPARE) IF OK THEN WRITE-LOG(READY) IF OK THEN WRITE-LOG(READY) MSG=READY MSG=READY ELSE MSG=NO ELSE MSG=NO SEND (C,MSG) SEND (C,MSG)

BDE-ARC 28 BDE Fase 2 C: RECEIVE(Pi,MSG) IF TIME-OUT OR ONE(MSG)=NO IF TIME-OUT OR ONE(MSG)=NO THEN WRITE-LOG(GLOBAL-ABORT) THEN WRITE-LOG(GLOBAL-ABORT) DECISION=ABORT DECISION=ABORT ELSE WRITE-LOG(GLOBAL-COMMIT) ELSE WRITE-LOG(GLOBAL-COMMIT) DECISION=COMMIT DECISION=COMMIT SEND(Pi,DECISION) SEND(Pi,DECISION) Pi: RECEIVE(C,DECISION) IF COMMIT THEN WRITE-LOG(COMMIT) IF COMMIT THEN WRITE-LOG(COMMIT) ELSE WRITE-LOG(ABORT) ELSE WRITE-LOG(ABORT) SEND (C,ACK) SEND (C,ACK) C: RECEIVE(Pi,ACK) WRITE-LOG(COMPLETE)

BDE-ARC 29 BDE Diagramma del commit a due fasi coordinatore partecipante t t PREPAREGLOBALDECISION READYLOCALDECISION PREPARE MSGDECISION COMPLETE ACK

BDE-ARC 30 BDE Protocollo 2PCommit con time-out e finestra di incertezza

BDE-ARC 31 BDE Incertezza Un RM dopo essersi dichiarato “ready” perde la sua autonomia e attende la decisione del TM. Un guasto del TM lascia l’RM in uno stato di incertezza, in cui tutte le risorse acquisite con lock sono bloccate. L’intervallo tra la scrittura dei record ready e commit o abort è chiamato finestra di incertezza. Il protocollo è progettato per minimizzare la sua durata.

BDE-ARC 32 BDE Complessità del protocollo Deve poter gestire tutti i guasti: Deve poter gestire tutti i guasti: - caduta del coordinatore - caduta di uno o più partecipanti - perdite di messaggi I protocolli di recovery sono svolti dai TM o RM dopo i guasti; ristabiliscono uno stato finale corretto

BDE-ARC 33 BDE Perdita di messaggi La perdita dei messaggi di “prepare” o “ready” sono indistinguibili; in entrambi i casi scatta il time-out sul TM e viene deciso un “global abort”. La perdita dei messaggi “decision” or “ack” sono pure indistinguibili. In entrambi i casi scatta il time-out sul TM e viene ripetuta la seconda fase.

BDE-ARC 34 BDE Recovery dei partecipanti Viene svolto con ripresa a caldo; per ogni transazione dipende dall’ultimo record (azione) nel log: –Se è una azione generica oppure un “ abort” tutte le azioni sono disfatte; se è un “ commit”, le azioni vengono rifatte; –Se è un “ ready”, il guasto è accaduto durante il commit a due fasi; il partecipante è in dubbio circa l’esito della transazione. Durante il protocollo di ripresa a caldo, si collezionano tutte le transazioni in dubbio; di esse si chiede l’esito ai rispettivi TM (richiesta di recovery remota).

BDE-ARC 35 BDE Recovery del coordinatore Quando l’ultimo record nel log è un “ prepare”, il guasto del TM può essere la causa di un blocco di qualche RM. Il TM ha due opzioni: –Scrivere “ global abort” sul log, e comunicare decisione ripetendo la seconda fase del protocollo di commit a due fasi –(Ripetere la prima fase, provando a raggiungere un commit globale) Quando l’ultimo record è la una “decisione globale”, alcuni RM potrebbero essere bloccati. Il TM deve ripetere la seconda fase del protocollo, ricomunicando la decisione.

BDE-ARC 36 BDE Protocollo di “abort presunto” E’ una ottimizzazione, usata da tutti i sistemi commerciali: –Se un TM riceve una richiesta di “remote recovery” da un RM in dubbio di cui non ha traccia, risponde per default che la transazione ha fatto un “global abort”

BDE-ARC 37 BDE Ottimizzazione “read-only” Quando un RM svolge solo operazioni di lettura, –Risponde read-only al messaggio di prepare message e esce dal protocollo. –Il TM ignora tutti gli RM “read-only” nella seconda fase del protocollo.

BDE-ARC 38 BDE Standardizzazione del protocollo Standard X-open Distributed Transaction Processing (DTP): Standard X-open Distributed Transaction Processing (DTP): - commit a 2 fasi con ottimizzazioni - molti DBMS sul mercato - molti DBMS sul mercato