Architetture distribuite
BDE-ARC 1
BDE
Basi di dati distribuite
a
RETE :
LAN (Local Area Network)
WAN (Wide Area Network)
b
DBMS :
Sistema omogeneo
Sistema eterogeneo
SYBASE
ORACLE
DB2
CLIENT
BDE-ARC 2
BDE
Problemi delle basi di dati distribuite
•
•
•
•
Autonomia vs cooperazione
Trasparenza
Efficienza
Affidabilità
BDE-ARC 3
BDE
Autonomia e cooperazione
L'esigenza di autonomia:
- Portare competenze e controllo
laddove vengono gestiti i dati
- Rendere la maggior parte delle
applicazioni NON distribuite (!)
L'esigenza di cooperazione:
- Alcune applicazioni sono intrinsecamente
distribuite e richiedono l'accesso a
piu' basi di dati
BDE-ARC 4
BDE
Frammentazione dei dati
Scomposizione delle tabelle in modo
da consentire la loro distribuzione
proprieta':
- Completezza
- Ricostruibilita'
BDE-ARC 5
BDE
Frammentazione orizzontale
FRAMMENTI:
insiemi di tuple
FR1
FR2
COMPLETEZZA:
presenza
di tutte le tuple
FR3
RICOSTRUZIONE:
unione
BDE-ARC 6
BDE
Frammentazione verticale
FRAMMENTI:
insiemi di attributi
COMPLETEZZA:
presenza
di tutti gli attributi
FR1 FR2 FR3
RICOSTRUZIONE:
join sulla chiave
BDE-ARC 7
BDE
Esempio: conti correnti bancari
CONTO-CORRENTE (NUM-CC,NOME,FILIALE,SALDO)
TRANSAZIONE (NPROG, NUM-CC,DATA, OPERAZIONE,
AMMONTARE, CAUSALE)
CENTRO
FILIALE1
FILIALE2
FILIALE3
BDE-ARC 8
BDE
Frammentazione orizzontale principale
Ri = 
Pi
R
esempio:
 Filiale=1 CONTO-CORRENTE
CONTO2 =  Filiale=2 CONTO-CORRENTE
CONTO3 =  Filiale=3 CONTO-CORRENTE
CONTO1 =
BDE-ARC 9
BDE
Frammentazione orizzontale
derivata
Si = S  Ri
esempio:
TRANS1 = TRANSAZIONE  CONTO1
TRANS2 = TRANSAZIONE  CONTO2
TRANS3 = TRANSAZIONE  CONTO3
BDE-ARC 10
BDE
Allocazione dei frammenti
CENTRO
CONTO1
TRANS1
CONTO2
TRANS2
CONTO3
TRANS3
CONTO1
CONTO2
CONTO3
TRANS1
TRANS2
TRANS3
FILIALE 1
FILIALE 2
FILIALE 3
BDE
BDE-ARC 11
Livelli di trasparenza
Modalita’ per esprimere interrogazioni
offerte dai DBMS commerciali:
LIVELLI: FRAMMENTAZIONE
ALLOCAZIONE
LINGUAGGIO
BDE-ARC 12
BDE
Trasparenza di frammentazione
QUERY :
estrarre il saldo del conto corrente 45
SELECT SALDO
FROM CONTO-CORRENTE
WHERE NUM-CC=45
BDE-ARC 13
BDE
Trasparenza di allocazione
IPOTESI : Allocazione incerta,
probabilmente alla filiale 1
SELECT SALDO FROM CONTO1
WHERE NUM-CC=45
IF (NOT FOUND) THEN
( SELECT SALDO FROM CONTO2
WHERE NUM-CC=45
UNION
SELECT SALDO FROM CONTO3
WHERE NUM-CC=45 )
BDE
BDE-ARC 14
Trasparenza di linguaggio
SELECT SALDO FROM CONTO1@1
WHERE NUM-CC=45
IF (NOT FOUND) THEN
( SELECT SALDO FROM CONTO2@2
WHERE NUM-CC=45
UNION
SELECT SALDO FROM CONTO3@3
WHERE NUM-CC=45 )
BDE-ARC 15
BDE
Efficienza
• Ottimizzazione delle query
• Modalita' di esecuzione
- seriale
- parallela
BDE-ARC 16
BDE
Esecuzione seriale
CENTRO
CONTO2
CONTO3
CLIENT
CONTO1
FILIALE1
BDE-ARC 17
BDE
Esecuzione parallela
CLIENT
CONTO1
CONTO2
CONTO3
FILIALE1
FILIALE2
FILIALE3
BDE-ARC 18
BDE
Protocolli di
commit
BDE-ARC 19
BDE
Transazioni distribuite
BEGIN TRANSACTION
UPDATE CONTO1@1
SET SALDO=SALDO + 500.000
WHERE NUM-CC=45;
UPDATE CONTO2@2
SET SALDO=SALDO - 500.000
WHERE NUM-CC=35;
COMMIT-WORK
END TRANSACTION
BDE-ARC 20
BDE
Transazioni distribuite
CLIENT
45
+ 500.000
35
FILIALE1
- 500.000
FILIALE2
BDE-ARC 21
BDE
Proprieta' ACIDe
dell’esecuzione distribuita
• Isolamento
se ciascuna
sottotransazione e' a due
fasi la transazione e'
globalmente serializzabile
• Persistenza
se ciascuna
sottotransazione gestisce
correttamente i log, i dati
sono globalmente
persistenti
• Consistenza
se ciascuna
sottotransazione
preserva l'integrita'
locale i dati sono
globalmente consistenti
• Atomicita'
e' il principale problema
delle transazioni
distribuite
BDE-ARC 22
BDE
Guasti in un sistema distribuito
• Caduta di nodi
• Perdita di messaggi
• Interruzione della rete
MSG
BDE-ARC 23
BDE
Protocolli distribuiti
e perdita di messaggi
A: SEND(B,MSG)
B:
RECEIVE(MSG)
SEND(A,ACK)
A: RECEIVE(ACK)
BDE-ARC 24
BDE
Commit a due fasi
Protocollo per garantire l'atomicita' di
sotto-transazioni distribuite
Protagonisti
- un coordinatore (Transaction Manager, TM)
- molti partecipanti (Resource Manager, RM)
Come un matrimonio
- fase uno: dichiarazione di intenti
- fase due: dichiarazione del matrimonio
BDE
BDE-ARC 25
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 26
BDE
Fase 1
C: WRITE-LOG(PREPARE)
SET TIME-OUT
SEND (Pi,PREPARE)
Pi: RECEIVE(C,PREPARE)
IF OK THEN WRITE-LOG(READY)
MSG=READY
ELSE MSG=NO
SEND (C,MSG)
BDE-ARC 27
BDE
Fase 2
C: RECEIVE(Pi,MSG)
IF TIME-OUT OR ONE(MSG)=NO
THEN WRITE-LOG(GLOBAL-ABORT)
DECISION=ABORT
ELSE WRITE-LOG(GLOBAL-COMMIT)
DECISION=COMMIT
SEND(Pi,DECISION)
Pi: RECEIVE(C,DECISION)
IF COMMIT THEN WRITE-LOG(COMMIT)
ELSE WRITE-LOG(ABORT)
SEND (C,ACK)
C: RECEIVE(Pi,ACK)
WRITE-LOG(COMPLETE)
BDE-ARC 28
BDE
Diagramma del commit a due fasi
PREPARE
coordinatore
GLOBAL
DECISION
COMPLETE
t
MSG
PREPARE
DECISION
ACK
partecipante
t
READY
LOCAL
DECISION
BDE-ARC 29
BDE
Protocollo 2PCommit con time-out e
finestra di incertezza
Prepare
Global Decision
time-out 1
Complete
time-out 2
TM
prepare
msg
ready
msg
Ready
decision
msg
ack
msg
Local Decision
RM
Finestra di incertezza
BDE-ARC 30
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 31
BDE
Complessità del protocollo
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 32
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 33
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 34
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 35
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 36
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 37
BDE
Standardizzazione del protocollo
Standard X-open Distributed Transaction
Processing (DTP):
- commit a 2 fasi con ottimizzazioni
- molti DBMS sul mercato
BDE-ARC 38
BDE