Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, Riccardo - Isa-Cnr

Transcript

Paolo Atzeni, Stefano Ceri, Stefano
Paraboschi, Riccardo Torlone
“Basi Di Dati”, Seconda Edizione
McGraw-Hill Italia, 1999
Capitolo 9
T r a n s a zi o n e
Insieme ordinato di operazioni di lettura e scrittura su un DB.
Sintatticamente:
•
•
inizia con un BoT (Begin of Transaction)
termina con un EoT (End of Transaction)
All’interno del codice:
•
•
Commit work
•
La transazione va a buon fine
Rollback work (abort)
•
La transazione non ha alcun effetto
Nei sistemi attuali è perlopiù garantito un solo livello di
controllo (transazioni flat).
Tecnologia di un DBMS
1
T r a n s a zi o n e
Transazione “Ben Formata”:
•
•
•
•
Inizia con BoT;
Termina con EoT;
Viene eseguito un solo Commit o un solo Abort;
Non avvengono letture e/o scritture dopo il Commit/Abort.
Proprietà garantita dai sistemi.
BoT
Update CC set saldo = saldo – 25 where ccnum = 26488
Update CC set saldo = saldo + 25 where ccnum = 26000
Commit
EoT
2
A CI Di t à d e l l e T r a n s a zi o n i
Atomicity:
•
Una transazione è una unità indivisibile.
Consistency:
•
Una transazione deve lasciare il DB in uno stato
consistente con i vincoli.
Isolation:
•
Una transazione deve agire in maniera indipendente dalle
altre.
Durability:
•
Gli effetti di una transazione che ha effettuato il Commit
non devono mai essere persi.
3
At om ic it à
Il modello di esecuzione è tutto-o-niente.
Una transazione può non andare a buon fine:
•
•
•
per decisione autonoma;
per decisione del DBMS;
per errori e/o guasti.
L’atomicità ci assicura che, indipendentemente dal momento e
dai motivi dell’abort, le eventuali azioni già effettuate vengono
disfatte (operazione di undo).
Durante l’esecuzione della transazione, le varie operazioni non
sono visibili al mondo esterno.
Dopo il commit, le operazioni effettuate sono tutte rese visibili
al mondo esterno.
4
Co n s i s t e n za
Una transazione lascia il DB in uno stato
consistente.
Vincoli Immediati:
•
•
se è violato un vincolo immediato, il corrispondente
comando ritorna un codice di errore;
se tale errore è gestito dal codice della transazione, questa
può provare a continuare.
Vincoli Ritardati:
•
•
il controllo sui vincoli deferred avviene quando è effettuato il
commit;
se qualche vincolo è violato, la transazione è uccisa in
extremis.
5
Isolam ent o
Per migliorare i tempi medi di risposta (TpS), è necessario
eseguire più transazioni in maniera concorrente.
La proprietà di isolamento garantisce che:
•
•
il risultato di un insieme di transazioni eseguite in maniera
concorrente è in qualche modo equivalente (?) a quello che si
otterrebbe se le transazioni fossero eseguite una dopo l’altra.
venga evitato il Rollback a catena (l’abort di una transazione
provoca l’abort di un’altra transazione e così via);
•
il Rollback a catena sarebbe particolarmente pericoloso qualora
coinvolgesse transazioni che hanno già effettuato il commit.
6
Du r a b i l i t y (Pe r s i s t e n za )
L’effetto di una transazione che ha effettuato
il commit non deve mai essere perso.
La persistenza fornisce meccanismi per
rispondere ai malfunzionamenti hw/sw del
sistema.
7
M o d u l i d i u n DB M S
Consistenza
Ottimizzatore
Persistenza
Gestore delle Strutture
Fisiche di Accesso
Controllore Affidabilità
Buffer Manager
Gestore Concorrenza
Atomicità
Isolamento
8
T e o r i a De l l a Co n c o r r e n za
Il gestore della concorrenza è lo strato più
interno di un DBMS.
Si occupa di trasferire:
blocchi in memoria centrale (read);
pagine verso la memoria di massa (write).
Scheduler:
gestisce le operazioni di lettura/scrittura.
9
Eq u i v a l e n za d i Sc h e d u l i n g
Si considerino 2 transazioni T1 e T2.
Esistono 2 scheduling sequenziali:
•
•
T1 T2
T2 T1
Non è detto che essi forniscano lo stesso risultato.
T1
BoT
Update CC set saldo = 0
Commit
EoT
T2
BoT
Update CC set saldo = saldo + 30
Commit
EoT
10
Eq u i v a l e n za d i Sc h e d u l i n g
Il risultato di un insieme di transazioni eseguite in maniera
concorrente è in qualche modo equivalente (?) a quello che si
otterrebbe se le transazioni fossero eseguite una dopo l’altra.
La teoria della concorrenza cerca di definire il concetto di
equivalenza di scheduling (sequenza di operazioni di I/O) in
maniera più o meno indipendente dal risultato che esse
producono.
Essa, inoltre, fornisce tecniche per evitare le anomalie delle
transazioni concorrenti.
Transazione
•
BoT ri(x) ri (y) wi (x) ri (z) wi (y) wi (z) C EoT
Commit Proiezione.
11
A n o m a l i e d e l l e T r a n s a zi o n i Co n c o r r e n t i
Perdita di Update
T1
BoT
r(x)
x = x+1
T2
T1
BoT
r(x)
Update Fantasma
T2
r(y)
BoT
r(x)
x = x+1
w(x)
commit
EoT
w(x)
commit
EoT
BoT
r(y)
y = y-500
r(z)
z = z+500
w(y)
w(z)
commit
EoT
r(z)
somma=x+y+z
commit
EoT
12
A n o m a l i e d e l l e T r a n s a zi o n i Co n c o r r e n t i
Letture Sporche
T1
T2
BoT
r(x)
x=x+1
w(x)
BoT
r(x)
x = x+1
w(x)
commit
EoT
abort
EoT
Letture Inconsistenti
T1
BoT
r(x)
T2
BoT
r(x)
x = x+1
w(x)
commit
EoT
r(x)
commit
EoT
13
V i e w Eq u i v a l e n za
Legge da: ri(x) legge-da wj(y)
•
•
•
x = y e i<>j;
nello scheduling ri segue wj;
non esiste wk(x) tra le operazioni
Scritture finali:
•
wk(x) è una scrittura finale se nello scheduling non esiste
alcuna scrittura su x successiva a k.
Due scheduling sono view-equivalenti se, oltre ad
effettuare le stesse operazioni, hanno le stesse
relazioni legge-da e le stesse scritture finali.
14
T1
BoT
Update CC set saldo = 0
Commit
EoT
T1
T2
w1(saldo)
r2(saldo) W2 (saldo)
T2
BoT
Select saldo into Lsaldo
Lsaldo = Lsaldo + 30
Update CC set saldo = Lsaldo
Commit
EoT
S1 = w1(saldo) r2(saldo) w2 (saldo)
S2 = r2(saldo) w2 (saldo) w1(saldo)
S3 = r2(saldo) w1(saldo) w2 (saldo)
15
V i e w Se r i a l i zza b i l i t à
Uno scheduling si dice view serializzabile se è viewequivalente ad almeno uno scheduling seriale.
Tale equivalenza è la più generale in assoluto:
•
due scheduling view-equivalenti producono lo stesso risultato.
Problemi:
•
•
•
verificare se due scheduling sono view-equivalenti è un problema
semplice;
verificare se è uno scheduling e view-serializzabile è un problema
NP-Completo;
le transazioni arrivano a istanti non specificati.
16
Co n f l i c t Eq u i v a l e n za
Diminuiamo il numero di scheduling
ammissibili restringendo il concetto di
equivalenza.
Conflitto
l’azione ai(x) è in conflitto con l’azione aj(y) sse:
• i <> j;
• x = y;
• almeno une delle due è una write;
• (ri(x),wj(x)) (wi(x),wj(x)) (wi(x) rj(x))
17
Co n f l i c t Eq u i v a l e n za
Due scheduling sono conflict-equivalenti sse, oltre
a presentare le stesse operazioni, hanno gli stessi
conflitti.
•
(ri(x),wj(x)) <> (wj(x) ri(x))
Uno scheduling è conflict- serializzabile se è
conflict equivalente ad uno scheduling seriale.
Esempio
•
•
S0 = r1(x) r2(y) w1(y) r3(y)r3(z)w2(x) w3(z)
(r1(x), w2(x)), (r2(y),w1(y)), (w1(y),r3(y))
18
T1
T2
T3
• Problemi:
– Verificare se un grafo è aciclico è
un problema semplice.
– Gestire il Grafo è complicato
– Le transazioni arrivano a istanti
non specificati.
– Nei casi reali non conosco cosa
vuole fare la transazione.
19
U n a s o l u zi o n e : i l p r o t o c o l l o 2 PL
Lock:
•
•
•
•
bloccare una risorsa che vogliamo utilizzare;
lock condiviso (per operazioni di lettura);
lock esclusivo (per operazioni di scrittura);
r_lock, w_lock, unlock.
Lo scheduler diventa un lock manager che riceve richieste di
lock e decide il da farsi.
Transazione ben formata rispetto al locking:
•
•
•
ogni operazioni di lettura è preceduta da un r_lock e seguita da
un unlock;
ogni operazioni di scrittura è preceduta da un w_lock e seguita da
un unlock;
proprietà garantita di compilatori.
20
Stato
Richiesta
R_locked
W_locked
Free
R_lock
OK / r_locked NO / W_locked OK / r_locked
W_lock
NO/ r_locked
NO / w_locked
OK / w_locked
Unlock
OK / dipende
OK / free
error
I lock garantiscono che sui dati si operi in maniera
mutuamente esclusiva.
Non garantiscono in alcun modo la serializzabilità.
21
Update Fantasma
T1
BoT
RL(x) /r(x) /UL(x)
T2
BoT
RL(y) / r(y) /UL(y)
RL(y) / r(y) /UL(y)
y = y-500
RL(z) / r(z) / UL(z)
z = z+500
WL(y) / w(y) / UL(y)
WL(z) / w(z) / UL(z)
commit
EoT
RL(z) / r(z) / UL(z)
somma=x+y+z
commit
EoT
22
Pr o t o c o l l o d i l o c k i n g a 2 f a s i
Una transazione, dopo
aver rilasciato un lock,
non può acquisirne altri.
In una transazione esiste
allora una fase crescente
(in cui i lock vengono
acquisiti) ed una fase
calante, in cui i lock
vengono rilasciati.
E’ concesso l’incremento
di lock.
VSR
CSR
2PL
23
Perdita di Update
T1
BoT
r(x)
x = x+1
T2
T1
BoT
r(x)
w(x)
BoT
r(x)
x = x+1
w(x)
commit
EoT
w(x)
commit
EoT
Letture Sporche
T2
BoT
r(x)
x = x+1
w(x)
commit
EoT
abort
EoT
24
2 PL s t r e t t o
Il problema è legato all’ipotesi di Commit
Proiezione che è alla base della teoria della
concorrenza.
Nei sistemi reali tale ipotesi deve, per forza
di cose, essere abbandonata.
2PL stretto:
al 2PL si aggiunge l’ulteriore condizione che le
risorse possono essere rilasciate solo dopo il
commit/abort.
25
De a d l o c k
Il meccanismo dei lock introduce un problema:
•
•
•
•
•
•
siano T1 e T2 due transazioni;
supponiamo che entrambe operino in scrittura su 2 oggetti
x e y;
T1 blocca x in scrittura;
T2 blocca y in scrittura;
T1 aspetta che T2 liberi y;
T2 aspetta che T1 liberi x.
La situazione può durare all’infinito.
26
De a d l o c k : 3 s o l u zi o n i p o s s i b i l i
Prevention:
Tecnica di prevenzione esatta:
•
•
le transazione acquisiscono le risorse di cui hanno bisogno
in un colpo solo;
se qualche risorsa non è disponibile, non viene assegnata
nessuna risorsa.
Problemi:
•
•
non sempre una transazione sa in partenza ciò di cui avrà
bisogno;
si rischia di bloccare troppi oggetti inutilmente.
27
Prevention
Tecnica approssimata:
•
•
•
tutte le transazioni richiedono i lock nello stesso ordine;
non sempre la transazione conosce tutto quello di cui avrà
bisogno;
non tutti i deadlock sono eliminati.
Tecnica approssimata:
•
•
•
ad ogni transazione è associato un timestamp;
se un lock non è concesso, la transazione aspetta solo se
essa è più giovane della transazione che detiene il lock;
non tutti i lock sono eliminati.
28
Detection:
Non si pongono vincoli alle transazioni.
Ad intervalli prefissati, o quando succede
qualcosa, il contenuto della tabella dei lock è
esaminato e comparato con le richieste pendenti.
Si costruisce un grafico delle richieste.
Se in tale grafico esiste un ciclo, c’è un deadlock.
Il ciclo deve essere spezzato uccidendo almeno
una transazione.
29
Time-out:
E’ la tecnica più semplice e più usata.
Ad richiesta di lock è associato un tempo
massimo di attesa.
Scaduto tale tempo, la richiesta si intende
rifiutata e la transazione uccisa.
30
Co n t r o l l o d i c o n c o r r e n za c o n
Tim est am ps
Ad ogni transazione viene assegnato un
identificativo numerico crescente nel tempo
Transazioni successive hanno identificativi via via
maggiori.
Ad ogni oggetto del DB viene associato
WTM(x), timestamp dell’ultima transazione che ha
scritto l’oggetto.
RTM(x) , timestamp dell’ultima transazione che ha
letto l’oggetto.
31
Allo scheduler la transazione con TS ts invia
richieste del tipo
read (x,ts)
•
•
Se ts < WTM(x), la richiesta non può essere soddisfatta e la
transazione richiedente viene uccisa.
Altrimenti la richiesta è accetta e RTM(x) è posto pari al
massimo tra ts e RTM(x) stesso.
write(x,ts)
•
•
Se ts < WTM(x) oppure ts < RTM(x) la transazione viene
uccisa.
Altrimenti la richiesta è accetta, WTM(x) è posto pari a ts.
32
Funziona solo nell’ipotesi di
commit-proiezione.
Nei casi reali le scritture
vanno bufferizzate in RAM
ed eseguite solo dopo il
commit.
Chi deve leggere deve
aspettare il commit (il lock
in qualche modo rientra).
Vengono uccise molte
transazioni.
VSR
CSR
2PL
TS
33
Livello di isolam ent o delle
T r a n s a zi o n i
Il livello di isolamento di una transazione determina
il comportamento della stessa.
Uncommitted Read
•
La transazione accetta di leggere dati modificati da una
transazione che non ha ancora fatto il commit (ignora i lock
esclusivi e non acquisisce lock in lettura).
Committed Read
•
La transazione non legge dati cambiati da una transazione
che non ha ancora fatto il commit.
Se però essa legge due volte lo stesso dato, può trovare
dati diversi.
34
Repeatable Read
Si aggiunge al commited read la caratteristica che,
se un dato è letto due volte, si avrà sempre lo
stesso risultato.
Serializable
Si aggiunge al Repeatable Read la caratteristica
che, se una query è fatta due volte, non vengono
aggiunte righe.
35
U n c o m m i t e d Re a d
Connection 1
Connection 2
SET TRANSACTION ISOLATION LEVEL
READ UNCOMMITTED
BEGIN TRAN
UPDATE authors
SET au_lname='Smith'
SELECT au_lname
FROM authors
WHERE au_lname='Smith'
ROLLBACK TRAN
SELECT au_lname
FROM authors
36
Co m m i t e d Re a d
Connection 1
Connection 2
READ COMMITTED
BEGIN TRAN
SELECT au_lname
FROM authors
UPDATE authors
SET au_lname='Smith'
SELECT au_lname
FROM authors
COMMIT TRAN
37
Re p e a t a b l e Re a d
Connection 1
Connection 2
REPEATABLE READ
BEGIN TRAN
SELECT au_lname
FROM authors
UPDATE authors
SET au_lname='Jones'
(la query si blocca)
SELECT au_lname
FROM authors
COMMIT TRAN
SELECT au_lname
FROM authors
38
Se r i a l i za b l e (1 /2 )
Connection 1
Connection 2
REPEATABLE READ
BEGIN TRAN
SELECT title FROM titles
WHERE title_id LIKE 'BU%'
INSERT titles
VALUES ('BU2000',
'Inside SQL Server 2000',
'popular_comp', '0877', 59.95,
5000, 10, 0, null, 'Sep 10, 2000')
--Risultato diverso!
COMMIT TRAN
39
Se r i a l i za b l e (2 /2 )
Connection 1
Connection 2
SERIALIZABLE
BEGIN TRAN
INSERT titles
VALUES ('BU3000',
'Itzik and His Black Belt SQL Tricks',
'popular_comp', '0877',
39.95, 10000, 12, 15000, null,
'Sep 15 2000')
(la query si blocca)
--Risultato uguale!
COMMIT TRAN
40
Re p e t e a b l e Re a d / Se r i a l i za b l e
Un modo alternativo per comprendere la differenza tra questi livelli di
isolamento è guardare alle modifiche possibili una volta che siano
stati modificati dati in un’altra transazione.
Nel REPEATABLE READ:
•
•
Le righe realmente lette non possono essere modificate o cancellate.
Possono però essere aggiunte righe anche nell’intervallo specificato nella
clausola Where della transazione che legge.
•
•
Tutti i dati letti sono read_locked;
Un insert non interferisce con questi lock.
Nel SERIALIZABLE:
•
•
Una volta che una transazione ha letto dati non sono possibili modifiche su di
essi.
Non sono possibili modifiche neanche all’interno dell’intervallo coperto nella
lettura.
•
SERIALIZABLE locka intervalli di dati, inclusi quelli di fatto non esistono,
impedendo cioè che vengano effettuati insert.
41
Du r a b i l i t y (Pe r s i s t e n za )
La Durability consente di reagire a:
Guasti di Sistema
Il server ha subito un guasto/malfunzionamento
che non ha danneggiato il dispositivo su cui è
memorizzato il DB.
Guasti di Dispositivo
Il dispositivo su cui è memorizzato il DB si è
danneggiato.
42
L o g Fi l e
La persistenza è assicurata tramite il file di
Log.
Il Log file è un file sequenziale memorizzato
su memoria stabile.
In esso esistono due tipi di di record:
Record di Transazione.
Record di Sistema.
43
Re c o r d d i T r a n s a zi o n e
Registrano le attività di ogni transazione, nell’ordine in cui
dette attività sono eseguite.
Ad ogni transazione è allora assegnato un identificativo.
Record di Begin, Commit, Abort:
•
Contengono l’identificativo della transazione ed il tipo di
operazione.
Record di Update:
•
Contengono l’identificativo della transazione, l’identificativo
dell’oggetto su cui si effettua l’update, lo stato prima dell’update
(BS) e lo stato dopo l’update (AS).
Record di Insert.
Record di Delete.
44
Re c o r d d i Si s t e m a
Record di dump:
•
Segnale che è stato effettuato un dump (copia di sicurezza
su memoria stabile) del DB.
Record di checkpoint:
•
•
•
Il checkpoint è una operazione che viene effettuata con una
certa frequenza da un DBMS.
In tale istante vengono riportato su disco le pagine
assegnate a transazioni che hanno effettuato il commit.
Alla fine viene scritto il record di checkpoint in cui si
riportano le transazioni attive a quell’istante.
45
Ri p r e s a a Ca l d o
Viene effettuato in risposta ad un guasto di
sistema.
Si accede all’ultimo blocco del log e si ripercorre il
file all’indietro fino all’ultimo record di chekpoint.
Si costruiscono due insiemi: Undo e Redo.
L’insieme di Redo è inizialmente vuoto mentre
l’insieme di Undo contiene le transazioni presenti
nel record di chekpoint.
46
Si ripercorre il log in avanti:
•
•
Se si incontra un Commit, la transazione corrispondente
viene spostata da Undo in Redo.
Se si incontra un Begin, la transazione corrispondente
viene inserita nell’insieme di Undo.
Si torna all’indietro fino al Begin della transazione
più vecchia fra tutte quelle presenti nei 2 insiemi.
Si ripercorre il Log all’indietro disfacendo le
operazione delle transazioni in UNDO
Si ripercorre il Log in avanti rifacendo le operazioni
delle transazioni in Redo
47
Ri p r e s a a Fr e d d o
Viene effettuato in risposta ad un guasto di
dispositivo.
Si ripristina il DB con l’ultima copia.
Si percorre il log in avanti, dall’ultimo dump,
rifacendo tutte le operazioni riportate.
Si effettua una ripresa a caldo.
48
Guasto
Funzionamento
Normale
Stop
Boot KO
Boot OK
Boot
Ripristino
E’ essenziale l’idempotenza delle operazioni di ripristino
49
Re g o l a WA L e Co m m i t Pr e c e d e n za
Il corretto funzionamento del meccanismo
presuppone che:
•
•
La parte BS sia scritta nel Log prima di effettuare modifiche
(WAL-Write Ahead Log).
La parte AS sia scritta prima del Commit (Commit
Precedenza)
In genere il record è scritto in un colpo solo prima
di effettuare modifiche sulla Base Dati (WAL
semplificata) e prima del Commit (Commit
Precedenza semplificata).
50
This document was created with Win2PDF available at http://www.daneprairie.com.
The unregistered version of Win2PDF is for evaluation or non-commercial use only.

Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, Riccardo - Isa-Cnr

Transcript

Documenti analoghi

Basi di dati e Web introduzione

db10- Sistemi informatici

transazione parmalat - bank of america

Tecnologia di un Database Server - Dipartimento di Matematica e

Modulo FAST CLAIM - Deutsche Bank Easy

Progettazione fisica

Scarica la scheda tecnica in PDF dedicata ai

base di dati