TRANSAZIONI

TRANSAZIONI
• Concetto di transazione, comandi di transazione, proprietà
ACID delle transazioni
• Transazioni concorrenti
–
–
–
–
–
Esecuzione seriale e serializzabile
Conflict-equivalenza, grafo dei conflitti
Protocollo 2PL e 2PL stretto
Protocollo basato su timestamp
Lo stallo
–
–
–
–
Malfunzionamenti, do/undo/redo
Il LOG
Checkpoint
Dump
• Gestione dei buffer
• Affidabilità
F.Cesarini - Basi Dati
Distribuite
Transazioni
1
TRANSAZIONI
• TRANSAZIONE
– una singola esecuzione di un programma
– una unità di lavoro effettuata da un’applicazione
– una unità di lavoro “consistente” e “affidabile”
F.Cesarini - Basi Dati
Distribuite
Transazioni
2
1
Esempio di transazione
• ESEMPIO: prenotazione di un volo da P1 a P3 con
cambio in P2
1. num. posti disponibili volo P1 P2 -2. num. posti occupati volo P1 P2 ++
3. num. posti disponibili volo P2 P3 -4. num. posti occupati volo P2 P3 ++
vincolo integrità: occupati + disponibili = k
•
malfunzionamento tra 1. e 2.
•
malfunzionamento tra 2. e 3.
– dati inconsistenti rispetto al vincolo di integrità
– dati consistenti rispetto al vincolo di integrità
– dati non corretti
F.Cesarini - Basi Dati
Distribuite
Transazioni
3
Esempio di transazione
• ESEMPIO: prenotazione di un volo da P1 a P3 con
cambio in P2
Istruzioni in linguaggio macchina
………
1 a. leggi num
1 b. somma 1
1 c. scrivi num
… … ...
•
esecuzione concorrente da parte di più transazioni di 1a., 1b.,
1c.
– il valore di num può non essere corretto
F.Cesarini - Basi Dati
Distribuite
Transazioni
4
2
Esecuzione di una transazione
database in uno
database in uno
stato consistente
stato consistente
il database può essere temporaneamente
in uno stato inconsistente
inizio transazione
fine transazione
esecuzione della transazione
F.Cesarini - Basi Dati
Distribuite
Transazioni
5
Esempio-1 di transazione [5]
FLIGHT (Fno,Date, Src, Dest, Seatsold, Capacity)
CUST (Cname, Addr, Bal)
FC (Fno, Date, Cname, Special)
Begin_transaction Reservation
begin
input (flight_no, date, customer_name);
EXEC SQL UPDATE FLIGHT
SET Seatsold = Seatsold + 1
WHERE Fno = flight_no
AND Date = date;
EXEC SQL INSERT INTO FC (Fno, Date, Cname, Special)
VALUES (flight_no, date, customer_name, NULL);
output (“reservation completed”)
end
Affinché l’esecuzione sia “corretta” devono essere eseguiti ambedue i comandi SQL
F.Cesarini - Basi Dati
Distribuite
Transazioni
6
3
TRANSAZIONI / COMANDI
BEGIN TRANSACTION
END TRANSACTION
COMMIT WORK
ROLLBACK WORK
•
•
i comandi begin transaction e end transaction racchiudono
le istruzioni che compongono il corpo della transazione
il comando commit work segnala al sistema che gli effetti
sul database devono essere resi permanenti
– deve essere eseguita una operazione di commit
•
il comando rollback work segnala al sistema che gli effetti
delle istruzioni eseguite fino a quel momento devono
essere annullati
– deve essere eseguita una operazione di abort
F.Cesarini - Basi Dati
Distribuite
Transazioni
7
TRANSAZIONI BEN FORMATE
•
una transazione è ben formata se
–
–
–
–
inizia con begin transaction
finisce con end transaction
esegue commit work o rollback work (o l’uno o l’altro)
dopo commit work o rollback work non esegue letture e/o
scritture sul database
•
si può vedere se una transazione è ben formata solo al
momento della sua esecuzione
•
non sempre i comandi visti devono essere scritti
esplicitamente dall’utente
si noti che l’operazione abort può essere eseguita dal
sistema a seguito dell’esecuzione di un rollback work, o
può essere decisa dal sistema autonomamente in base alla
situazione
•
F.Cesarini - Basi Dati
Distribuite
Transazioni
8
4
TRANSAZIONI / COMANDI SQL
•
•
•
•
•
•
•
commit
rollback
non esistono begin transaction e end transaction
una istruzione SQL è implicitamente la prima istruzione di
una transazione (transazione corrente) se non esiste già
una transazione corrente
i comandi commit e rollback segnalano anche la fine della
transazione
ogni istruzione SQL che segue un commit o un rollback è la
prima istruzione di una nuova transazione
il comando set transaction serve ad eventualmente definire
le caratteristiche della transazione corrente
F.Cesarini - Basi Dati
Distribuite
Transazioni
9
Esempio-2 di transazione [5]
FLIGHT (Fno,Date, Src, Dest, Seatsold, Capacity)
CUST (Cname, Addr, Bal)
FC (Fno, Date, Cname, Special)
Begin_transaction Reservation
begin
input (flight_no, date, customer_name);
EXEC SQL SELECT Seatsold, Capacity INTO temp1, temp2
FROM FLIGHT WHERE Fno = flight_no AND Date =
date;
if temp1 = temp2 then begin
output (“no free seats”);
Rollback
end
else …..
F.Cesarini - Basi Dati
Distribuite
Transazioni
10
5
Esempio-2 di transazione [5]
FLIGHT (Fno,Date, Src, Dest, Seatsold, Capacity)
CUST (Cname, Addr, Bal)
FC (Fno, Date, Cname, Special)
…..
begin
EXEC SQL UPDATE FLIGHT
SET Seatsold = Seatsold + 1
WHERE Fno = flight_no
AND Date = date;
EXEC SQL INSERT INTO FC (Fno, Date, Cname, Special)
VALUES (flight_no, date, customer_name, NULL);
Commit;
output (“reservation completed”)
end
end-if
end
F.Cesarini - Basi Dati
Distribuite
Transazioni
11
TRANSAZIONI / PROPRIETA’
proprietà acide delle transazioni
•
•
•
•
Atomicity
Consistency
Isolation
Durability
F.Cesarini - Basi Dati
Distribuite
ACID
atomicità
consistenza
isolamento
persistenza
Transazioni
12
6
TRANSAZIONI / ATOMICITA’
•
la transazione è una unità di elaborazione indivisibile: tutto
o niente
•
se la transazione esegue un commit tutte le sue modifiche
vengono rese permanenti e visibili alle altre transazioni
•
se la transazione va in abort , è come se non fosse mai
iniziata
– il sistema deve riportare lo stato del database a quello che si
aveva prima dell’inizio della transazione
– il sistema deve disfare quello che la transazione ha fatto
•
l’abort può essere provocato da
– esecuzione di un rollback
– malfunzionamento che causa l’interruzione della transazione
– decisione del sistema ad esempio nel trattamento dello stallo
F.Cesarini - Basi Dati
Distribuite
Transazioni
13
TRANSAZIONI / CONSISTENZA
• una transazione non deve violare i vincoli di
integrità definiti sul database
• i vincoli di integrità possono essere controllati in
– modo immediato, dopo ogni aggiornamento
– modo differito, al momento del commit
• es: inserimenti in tabelle con vincoli di integrità
referenziale ciclici
– Se i vincoli sono controllati in modo immediato, non è
possibile fare nessun inserimento
F.Cesarini - Basi Dati
Distribuite
Transazioni
14
7
TRANSAZIONI / ISOLAMENTO
•
•
•
l’esecuzione di una transazione è indipendente dall’esecuzione
concorrente di altre transazioni
le modifiche fatte da una transazione sulla base di dati sono
visibili alle altre transazioni solo dopo che questa ha effettuato
il commit
esempio di esecuzione concorrente, non isolata di T1 e T2
… … write 1(x) read2(x) commit2 abort1
il dato x letto da T2 non è valido: T2 deve essere disfatta e
rifatta
F.Cesarini - Basi Dati
Distribuite
Transazioni
15
TRANSAZIONI / PERSISTENZA
• Gli effetti sul database di una transazione andata
in commit sono permanenti, non devono andare
persi per nessun motivo (es. malfunzionamenti)
F.Cesarini - Basi Dati
Distribuite
Transazioni
16
8
TRANSAZIONI CONCORRENTI
T1
T2
r1(x); e1: x=x+100; w1(x); commit1
r2(x); e2: x=x-200; w2(x); commit2
x0: 1000
esecuzione concorrente r1(x) r2(x) e2 e1 w2(x) w1(x) c1 c2
xf: 1100
risultato non corretto
esecuzione seriale di transazioni
una esecuzione di T={T1, … Tn} è seriale se ∀(Ti, Tj) tutte le
operazioni di Ti vengono eseguite prima di Tj o viceversa
esecuzione serializzabile di transazioni
una esecuzione di T={T1, … Tn} è serializzabile se ha sul DB
lo stesso effetto di una esecuzione seriale
una esecuzione serializzabile è corretta
F.Cesarini - Basi Dati
Distribuite
Transazioni
17
ESEMPI ESECUZIONE CONCORRENTE
T1
T2
T3
r1(x); e1: y=x+1; w1(y); c1
r2(y); e2: z=y+1; w2(z); c2
r3(z); e3: x=z+1; w3(x); c3
x0 = y0 = z0 = 0
esecuzione seriale T1 T2 T3
r1 e1 w1 c1 r2 e2 w2 c2 r3 e3 w3 c3 ⇒ x=3
y=1 z=2
≡ T1 T3 T2)
esecuzione serializzabile (≡
r1 r3 e3 w3 c3 e1 w1 c1 r2 e2 w2 c2
⇒ x=1 y=1 z=2
esecuzione non serializzabile
r2 r1 r3 e2 w2 c2 e1 w1 c1 e3 w3 c3
⇒ x=1 y=1 z=1
F.Cesarini - Basi Dati
Distribuite
Transazioni
18
9
ESEMPI ESECUZIONE CONCORRENTE
esecuzione seriale
T1
T2
r(A) A=A-1 w(A) r(B) B=B+1 w(B) c
r(B) B=B-2 w(B)
r(C) C=C+2 w(C) c
esecuzione serializzabile
T1
T2
r(A)
A=A-1
r(B)
w(A)
B=B-2
r(B)
w(B)
B=B+1
r(C)
w(B) c
C=C+2
w(C)
c
esecuzione non serializzabile
T1
T2
r(A) A=A-1
w(A)
r(B)
r(B)
B=B-2
B=B+1
w(B)
w(B)
r(C)
c
C=C+2
w(C)
c
T1 legge B prima che T2 l’abbia aggiornato
F.Cesarini - Basi Dati
Distribuite
Transazioni
19
SCHEDULE (STORIA) DI TRANSAZIONI
•
•
consideriamo solo le operazioni: lettura, scrittura, commit,
abort
nessuna transazione legge o scrive un dato più di una volta
l’esecuzione di Ti è un ordinamento su un insieme di
operazioni
Oi ⊂ {ri(x), wi(x)} ∪ { ci, ai}
tale che
– solo una delle due operazioni commit o abort è presente
– l’ultima operazione è commit o abort
Dato T= {T1 … Tn} una storia (schedule) S su T è un
ordinamento su un insieme di operazioni
O = ∪i O i
che rispetta l’ordinamento di ogni Ti
F.Cesarini - Basi Dati
Distribuite
Transazioni
20
10
CONFLICT-EQUIVALENZA DI STORIE
•
•
•
•
due operazioni p e q sono in conflitto se operano sullo
stesso dato e almeno una di esse è una scrittura
in questo contesto, consideriamo solo transazioni
terminate da un commit (commit-proiezione di storie)
due storie S1 e S2 sono conflict-equivalenti se contengono
le stesse operazioni e ordinano allo stesso modo
operazioni in conflitto
una storia è conflict-serializzabile se è conflict-equivalente
ad una storia seriale
F.Cesarini - Basi Dati
Distribuite
Transazioni
21
CONFLICT-EQUIVALENZA esempi
T1 r1(x) w1(x) w1(y) c1
T2 r2(x) w2(y) c2
T3 r3(x) w3(x) c3
S1
S2
S3
r2(x) r1(x) w1(x) r3(x) w1(y) c1 w2(y) c2 w3(x) c3
r1(x) r2(x) w1(x) r3(x) w3(x) c3 w1(y) w2(y) c2 c1
r2(x) r1(x) w1(x) r3(x) w3(x) c3 w2(y) w1(y) c2 c1
S1 c-equiv S2
S1 non è c-equiv S3
S3 è c-serializzabile
S3 è c-equiv storia seriale T2 T1 T3
S1 non è c-serializzabile
F.Cesarini - Basi Dati
Distribuite
Transazioni
22
11
GRAFO DEI CONFLITTI
grafo dei conflitti relativo alla storia S: CG(S)
– ad ogni transazione corrisponde un nodo
≠j) se e solo se almeno una operazione
– si ha un arco Ti → Tj (i≠
di Ti precede e va in conflitto con una operazione di Tj
S2
r1(x)
r2(x)
w1(x) r3(x) w3(x) c3 w1(y) w2(y) c2 c1
T3
T2
S3
r2(x)
T1
r1(x) w1(x) r3(x) w3(x) c3 w2(y) w1(y) c2 c1
T3
T2
F.Cesarini - Basi Dati
Distribuite
T1
Transazioni
23
TEOREMA DI SERIALIZZABILITA’
una storia S è conflict-serializzabile se e solo se il
suo grafo dei conflitti è aciclico
S2 non è conflict-serializzabile
S3 è conflict-serializzabile
determinare se un grafo è aciclico ha complessità lineare
rispetto al numero dei nodi
grafi grandi e dinamici
F.Cesarini - Basi Dati
Distribuite
Transazioni
24
12
CONTROLLO CONCORRENZA: lock
vincoli sulle operazioni lettura/scrittura effettuate
dalle transazioni:
•
ogni operazione di lettura deve essere preceduta dalla
richiesta read_lock e seguita da read_unlock
r_lock(x) … read(x) … r_unlock(x)
•
ogni operazione di scrittura deve essere preceduta dalla
richiesta write_lock e seguita da write_unlock
w_lock(x) … write(x) … w_unlock(x)
•
transazioni che seguono questo protocollo sono ben
formate rispetto al locking
F.Cesarini - Basi Dati
Distribuite
Transazioni
25
CONTROLLO CONCORRENZA: lock
gestione dei lock:
•
i lock sono gestiti dal lock manager che tiene traccia dei
lock assegnati alle varie transazioni
– tabella dei lock:
•
•
•
•
•
•
[dato_id, tipo_lock, transazione_id]
un r_lock(x) viene accordato solo se non è già stato
assegnato un w_lock(x)
un w_lock(x) viene accordato solo se nessun tipo di lock su
x è già stato assegnato (la risorsa x è libera)
se una T ottiene un lock continua la sua esecuzione
se una T non ottiene un lock, ne viene sospesa
l’esecuzione in attesa di poterlo ottenere
una operazione di unlock annulla l’assegnazione del
corrispondente lock
ad ogni operazione unlock(x) il lock manager controlla se ci
sono T in attesa di un lock(x) e se è possibile accordarlo
F.Cesarini - Basi Dati
Distribuite
Transazioni
26
13
PROTOCOLLO 2PL two phase locking
una transazione non può ottenere nessun lock dopo
aver effettuato un unlock
storia 2PL: esecuzione concorrente di transazioni
che seguono il protocollo 2PL
num. di
lock
ottenuti
t
begin
F.Cesarini - Basi Dati
Distribuite
end
Transazioni
27
SERIALIZZABILITA’ DELLE STORIE 2PL
• il grafo dei conflitti di una storia 2PL è
aciclico
• una storia 2PL è quindi serializzabile
F.Cesarini - Basi Dati
Distribuite
Transazioni
28
14
PROTOCOLLO A DUE FASI STRETTO
strict 2PL
•
•
consideriamo situazioni reali in cui ci possono essere abort
il protocollo 2PL non garantisce l’isolamento
– w_l1(x) w1(x) w_u1(x) r_l2(x) r2(x) r_u2(x) c2 a1
•
protocollo 2PL stretto: una transazione esegue tutti gli
unlock solo dopo il commit (abort)
num.
lock
t
begin
•
commit
end
Il protocollo 2PL stretto limita il grado di concorrenza ma dà
l’isolamento
F.Cesarini - Basi Dati
Distribuite
Transazioni
29
CONTR. CONCORRENZA / TIMESTAMP
•
•
ad ogni transazione viene assegnato un timestamp (marca
temporale)
i timestamp sono ordinati in modo consistente con l’inizio
esecuzione delle transazioni
– valore dell’orologio, intero progressivo, …
•
obbiettivo scheduler TS: esecuzione di storie serializzabili
equivalenti alla storia seriale corrispondente
all’ordinamento dei timestamp
•
ad ogni dato x vengono associati
– max_read(x)
– max_write(x)
F.Cesarini - Basi Dati
Distribuite
timestamp più grande delle T che hanno
letto x
timestamp più grande delle T che hanno
scritto x
Transazioni
30
15
CONTR. CONCORRENZA / TIMESTAMP
gestione richieste lettura e scrittura da parte di T con
timestamp ts
read(x, ts)
write(x, ts)
read(x, ts):
se
se
ts<max_write(x) allora T viene abortita
ts>max_write(x) allora l’operazione
viene accettata e
max_read(x) ← max(ts, max_read(x))
write(x, ts):
se ts<max_write(x) oppure
ts<max_read(x)
allora T viene abortita
altrimenti l’operazione viene accettata e
max_write(x) ← ts
gestione corretta nell’ipotesi di commit proiezione (non si ha
isolamento)
F.Cesarini - Basi Dati
Distribuite
Transazioni
31
Confronto
•
•
•
CS: insieme delle storie conflict-serializzabili
2PL: insieme delle storie ottenibili con il protocollo 2PL
TS: insieme delle storie ottenibili con il controllo basato su timestamp
CS
2PL
F.Cesarini - Basi Dati
Distribuite
TS
Transazioni
32
16
Confronto
S: r1(x) w1(x) r2(x) w2(x) r3(y) w1(y)
S è conflict-serializzabile, equivalente alla storia seriale T3 T1 T2
S non è 2PL perché T1 ha rilasciato x (altrimenti T2 non avrebbe potuto
leggerlo) e poi ha chiesto un lock in scrittura su Y
T1
T2
T3
F.Cesarini - Basi Dati
Distribuite
Transazioni
33
Confronto
S: r1(x) w2(x) r3(x) r1(y) w2(y) r1(v) w3(v) r4(v) w4(y) w5(y)
↑_________________↑
↑
non 2PL
S è conflict-serializzabile, equivalente alla storia seriale T1 T2 T3 T4 T5
S è compatibile con il protocollo basato su timestamp
S non è 2PL perché T2 ha rilasciato x (altrimenti T3 non avrebbe potuto
leggerlo) e poi ha chiesto un lock in scrittura su Y
T1
T2
T5
T4
F.Cesarini - Basi Dati
Distribuite
T3
Transazioni
34
17
Confronto
S: r1(x) w1(x) r2(x) w2(x)
S è 2PL e anche TS
S: r2(x) w2(x) r1(x) w1(x)
S è 2PL ma chiaramente non è TS
F.Cesarini - Basi Dati
Distribuite
Transazioni
35
STALLO
•
•
Con i protocolli basati su lock possono verificarsi situazioni di stallo
Esempio di stallo
r_lk1(x) r_lk2(y) r1(x) r_2(y) w_lk1(y) w_lk2(x)
– La transazione T1 chiede un lock in scrittura su y e viene messa in attesa
perché y è bloccato da T2
– La transazione T2 chiede un lock in scrittura su x e viene messa in attesa
perché x è bloccato da T1
– Nessuna delle due transazioni può andare avanti
•
•
La probabilità che si verifichi uno stallo è bassa ma non nulla
In caso di stallo il grafo delle attese presenta un ciclo
– T1 attende che T2 rilasci y e T2 attende che T1 rilasci x
y
T1
T2
x
F.Cesarini - Basi Dati
Distribuite
Transazioni
36
18
Tecniche per lo stallo: timeout
•
•
Viene stabilito un limite per il tempo che una transazione può stare in
attesa di un lock, scaduto il timeout viene mandata in abort
Importanza della scelta di un intervallo adeguato
– Troppo corto: abort non necessario perché in realtà invece di uno stallo si
aveva un’attesa “lunga”
– Troppo lungo: permanenza del sistema in stallo prima di prendere
provvedimenti
•
•
Tecnica semplice
Tecnica spesso usata dai DBMS commerciali
F.Cesarini - Basi Dati
Distribuite
Transazioni
37
Tecniche per lo stallo: prevenzione
•
•
Con questo tipo di tecniche si seguono dei protocolli che fanno sì che
non possa verificarsi uno stallo
Cfr. sistemi operativi: tecniche che impediscono una delle quattro
condizioni necessarie per lo stallo
– Acquisendo all’inizio tutte le risorse necessarie, si nega la condizione
“possesso e attesa”
– Con il protocollo che vedremo basato sui timestamp, si impediscono cicli
nel grafo delle attese
•
Tecnica A: richiedere inizialmente tutti i lock necessari
– Non è facile da utilizzare perché non sempre le transazioni conoscono a
priori tutti i dati che hanno bisogno di bloccare
F.Cesarini - Basi Dati
Distribuite
Transazioni
38
19
•
•
•
Tecniche per lo stallo: prevenzione
basata su timestamp
Ad ogni T viene assegnato un timestamp, sia i il timestamp assegnato a
Ti:
Ti aspetta per un dato posseduto da Tj se e solo se i <j , cioè
se e solo se Ti è più vecchia di Tj
altrimenti Ti viene mandata in abort e fatta ripartire con lo stesso
timestamp
Delle due transazioni, viene eventualmente mandata in abort la più
giovane (si suppone che abbia fatto meno lavoro da disfare)
È una tecnica senza preemption (Tj mantiene il dato che ha bloccato)
– Ci sono protocolli simili che invece effettuano una preemption
•
•
•
Ripartire con lo stesso timestamp “invecchia” la transazione, e
impedisce che in caso di conflitto sia sempre quella ad andare in abort
Si può facilmente dimostrare che con questa tecnica il grafo delle attese
non ha mai cicli (si dimostra per assurdo)
Tecnica non usata nei DBMS commerciali: troppi abort
F.Cesarini - Basi Dati
Distribuite
Transazioni
39
Tecniche per lo stallo: rilevamento
•
Ricerca di un ciclo nel grafo delle attese / Analisi delle tabelle di lock
– Es:
Lock assegnati a T
Transazioni in attesa di lock
lock Trans
Trans
lock
r_l(x)
Ti
Tk
r_l(y)
w_l(y)
Ti
Ti
w_l(u)
w_l(z)
Tj
r_l(u)
Tk
Esaminando le due tabelle si può verificare se siamo in stallo o no
•
Quando effettuare il controllo
– Periodicamente
– Quando scade un timeout
•
Tecnica usata da alcuni DBMS commerciali
F.Cesarini - Basi Dati
Distribuite
Transazioni
40
20
GESTIONE DEI BUFFER
•
•
BUFFER: area in memoria centrale spartita tra le transazioni
area buffer organizzata in pagine
•
lettura del dato x da parte della transazione T:
– dim. pagina ⇔ dim. blocco I/O disco utilizzato dal sistop
– determinazione file e blocco-disco B dove x è memorizzato
– controllo se B è in una pagina P di BUFFER
• SI: T legge da P
• NO: il sistema legge B in una pagina P di BUFFER; T legge da P
•
scrittura del dato y da parte della transazione T:
– determinazione file e blocco-disco B dove y è memorizzato
– controllo se B è in una pagina P di BUFFER
• SI: T scrive su P
• NO: il sistema legge B in una pagina P di BUFFER; T scrive su P
– scrittura di P su disco (questa scrittura può essere differita)
•
numero di pagine è limitato: politica di sostituzione
F.Cesarini - Basi Dati
Distribuite
Transazioni
41
Buffer
…
read(x)
…
x: …
…
x
F.Cesarini - Basi Dati
Distribuite
…
write(y)
…
y: …
…
buff_1
buff_1
x
y
buff_k
buff_k
Transazioni
y
42
21
STRUTTURE DEL BUFFER MANAGER
•
•
•
tabella allocazione pagine:
< pagina-buffer, file, blocco-disco, valida, libera>
(file, blocco-disco) ⇔ pagina database
Pagina-buffer valida/non valida
– valida: pagina in uso ad una transazione
– non valida: pagina non in uso ad alcuna transazione
– In genere con una richiesta di lettura si ha una pagina in uso
ad una transazione, quindi valida; quando la transazione non
la usa più, la “rilascia” e diventa non valida
•
Pagina-buffer libera/non libera
– libera: pagina che può essere usata per leggere un nuovo
blocco
– non libera: pagina che deve essere copiata su disco prima di
usarla per leggere un nuovo blocco
F.Cesarini - Basi Dati
Distribuite
Transazioni
43
PRIMITIVE DEL BUFFER MANAGER
•
Operazione fetch ( o fix, use)
•
operazione force su pagina P del buffer richiesta da T:
– Viene usata per leggere una pagina in un buffer
– la pagina P viene copiata su disco e T viene sospesa fino al
termine della scrittura
•
operazione flush (su pag P del buffer) del buffer manager:
– la pagina P non più valida, quindi non più usata da una
transazione, (e ancora non libera) viene copiata su disco
– Questa scrittura è asincrona rispetto all’esecuzione delle
transazioni
F.Cesarini - Basi Dati
Distribuite
Transazioni
44
22
POLITICHE GESTIONE PAGINE BUFFER
•
steal / no-steal
– steal: nella sostituzione delle pagine, la vittima può essere
anche una pagina valida
• prima di essere sostituita deve essere copiata su disco
• se la transazione, che aveva in uso la pagina,
successivamente va in abort, deve essere ripristinato il
valore iniziale della pagina del database
– no-steal: nella sostituzione delle pagine la vittima non può
essere una pagina valida
•
force / no-force
– force: tutte le pagine attive di una transazione T vengono
copiate su disco quando T effettua il commit
– no-force: la scrittura delle pagine su disco viene gestita dal
buffer manager in modo asincrono rispetto alla transazione (la
scrittura può essere effettuata dopo il commit)
•
DBMS: no-steal/ no-force coppia molto frequente
F.Cesarini - Basi Dati
Distribuite
Transazioni
45
MALFUNZIONAMENTI E AFFIDABILITA’
•
fallimento di transazione: nessuna perdita di dati né in
memoria centrale né su disco
–
–
–
–
–
–
•
interruzione da parte dell’utente
errore di esecuzione
violazione vincoli integrità
tentativo accedere a dati protetti
situazioni di stallo
…
fallimento di sistema (guasto di sistema): perdita del
contenuto della memoria centrale
– anomalia hard/sw con interruzione di tutte le transazioni attive
– caduta di tensione
– …
•
disastro / crash (guasto di dispositivo): malfunzionamento
che danneggia il disco
F.Cesarini - Basi Dati
Distribuite
Transazioni
46
23
Local Recovery Manager e Buffer Manager
Main memory
Local Recovery
Manager
fetch
flush
Database
stabile
F.Cesarini - Basi Dati
Distribuite
read
write
Database Buffer
Manager
read
write
Database
Buffers
o
Database
volatile
Transazioni
47
AFFIDABILITA’
•
il controllo dell’affidabilità garantisce le proprietà di
atomicità e persistenza delle transazioni
– atomicità: se la transazione va in abort o si ha un guasto di
sistema prima del commit, la transazione viene disfatta (undo)
– persistenza: se una transazione ha effettuato il commit ma non
si è sicuri dei suoi risultati sul database, la transazione viene
rifatta (redo)
•
memoria stabile: resistente ai guasti (non subisce crash)
– unità a nastro
– disco + unità a nastro
– due dischi “a specchio” …
•
•
•
•
protezione da malfunzionamenti: ridondanza dei dati
log (giornale): file su cui vengono registrate le azioni
eseguite dalle transazioni
checkpoint
dump
F.Cesarini - Basi Dati
Distribuite
Transazioni
48
24
DO / UNDO / REDO
… <scrittura pag. modificata>; commit
↑
fallimento di transazione
DB modificato
UNDO
DB senza modifiche
vecchi valori
… commit; … <scrittura pag. modificata>
↑
fallimento di sistema
DB senza modifiche
REDO
DB modificato
nuovi valori
F.Cesarini - Basi Dati
Distribuite
Transazioni
49
STRUTTURA DEL LOG
•
•
file sequenziale su memoria stabile in cui vengono
registrate le azioni effettuate sul database nell’ordine
temporale di esecuzione
azioni eseguite dal sistema
– dump
– checkpoint
•
azioni eseguite dalle transazioni
–
–
–
–
Begin (T)
Commit (T)
Abort (T)
Update (T, Object, Before State, After State)
Insert (T, Object, After State)
Delete (T, Object, Before State)
… CK ... B(T 1) … I(T 1,Ox, AS) … C(T 2) … U(T 1, Oy, BS, AS) … C(T 1) …
F.Cesarini - Basi Dati
Distribuite
Transazioni
50
25
USO DEL LOG
• undo e redo utilizzano BS e AS (Before State e
After State)
• idempotenza:
undo(azione)=undo(undo(azione))
redo(azione)=redo(redo(azione))
• i record di log vengono scritti sequenzialmente
su un buffer che generalmente viene copiato sul
file log quando è pieno
F.Cesarini - Basi Dati
Distribuite
Transazioni
51
Logging
Main memory
fetch
flush
Database
stabile
F.Cesarini - Basi Dati
Distribuite
read
write
Database Buffer
Manager
Transazioni
te
d
wr
it e
LOG
buffers
Local Recovery
Manager
wri
re
a
rea
d
LOG
stabile
read
write
Database
Buffers
o
Database
volatile
52
26
CHECKPOINT / DUMP
•
checkpoint: operazione fatta periodicamente dal sistema
per limitare la parte di giornale da scandire in caso di
malfunzionamenti
– rifiuta una nuova operazione di commit
– scrive su disco le pagine P del buffer modificate, relative a
transazioni che hanno effettuato un commit
– scrive nel log un record checkpoint(T1, … Tn) che indica le
transazioni attive in quel momento
•
•
dopo un checkpoint le modifiche sul database effettuate in
precedenza da transazioni terminate sono sicuramente su
disco
dump: copia completa del database
–
–
–
–
–
rifiuta l’attivazione di nuove transazioni
attende il completamento delle transazioni attive
scrive su disco le pagine P del buffer modificate
fa una copia del database (backup)
scrive nel log un record dump
F.Cesarini - Basi Dati
Distribuite
Transazioni
53
GESTIONE SCRITTURA SUL LOG
•
regola WAL, Write Ahead LOG: il Before State di un record
di log deve essere scritto sul file log (in memoria stabile)
prima che la modifica sull’oggetto venga scritta sul
database su disco
– si è sicuri che quando il nuovo valore viene scritto su disco il
vecchio valore sia stato salvato nel log, così si può
eventualmente recuperarlo
•
regola CP, Commit-Precedenza: l’After State di un record di
log deve essere scritto sul file log (in memoria stabile)
prima del commit
– se una transazione effettua il commit, ma le sue pagine
modificate non sono state ancora riportate su disco dal buffer
manager, e si verifica un malfunzionamento di sistema, la
transazione deve essere rifatta
– con la regola Commit- Precedenza si è sicuri di ritrovare i dati
modificati (After State) nel log
F.Cesarini - Basi Dati
Distribuite
Transazioni
54
27
GESTIONE SCRITTURA LOG E DATABASE
• schema no-redo
– la scrittura del record log precede la scrittura sulla base di dati
– tutte le pagine modificate vengono copiate su disco prima
della scrittura del record commit sul log
• schema no-undo
– la scrittura del record log precede la scrittura sulla base di dati
– tutte le pagine modificate vengono copiate su disco dopo la
scrittura del record commit sul log
• schema undo/redo (DB2, ORACLE)
– le scritture sul database su disco possono avvenire in un
momento qualunque rispetto alla scrittura del commit sul log
•
i tre schemi rispettano le regole WAL e CP, scrivono il
commit su disco in modo sincrono, si differenziano per il
momento in cui scrivono sul database su disco
F.Cesarini - Basi Dati
Distribuite
Transazioni
55
GESTIONE GUASTI
MODELLO FAIL-STOP (guasto: evento istantaneo)
•
guasto di sistema
– arresto di tutte le transazioni
– ripresa a caldo (warm restart) del sistema
•
guasto di dispositivo
– arresto di tutte le transazioni
– ripresa a freddo (cold restart) del sistema
F.Cesarini - Basi Dati
Distribuite
Transazioni
56
28
WARM RESTART
CKP
guasto
t
T2
T1
T3
T4
T5
UNDO:
REDO:
T3
T2
T5 completamente
T4
Si ricordi che il checkpoint copia su disco le scritture effettuate dalle
transazioni andate in commit
F.Cesarini - Basi Dati
Distribuite
Transazioni
57
WARM RESTART
1. si accede al log e lo si percorre all’indietro fino all’ultimo
ckp
2. si costruiscono gli insiemi UNDO_set e REDO_set
3. si disfano le transazioni di UNDO_set ripercorrendo
all’indietro il log fino al loro inizio (anche prima di ckp)
4. si rifanno le transazioni in REDO_set rifacendo le loro
azioni nell’ordine in cui compaiono nel log
2.1
2.2
2.3
UNDO_set:= transazioni elencate nel ckp record
REDO_set:= ∅
si scandisce il log:
se Begin(T) allora UNDO_set:= UNDO_set ∪ T
se Commit(T) allora UNDO_set:= UNDO_set - T
REDO_set:= REDO_set ∪ T
F.Cesarini - Basi Dati
Distribuite
Transazioni
58
29
COLD RESTART
• si ricopia il database (la parte deteriorata) dal
dump più recente
• si accede all’ultimo record dump sul log
• si scandisce il log rifacendo tutte le azioni
effettuate sul database dalle transazioni andate in
commit
• si effettua una ripartenza a caldo
F.Cesarini - Basi Dati
Distribuite
Transazioni
59
30