Gestione delle transazioni

Gestione delle transazioni
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
1
Transazioni
v
L’esecuzione concorrente dei programmi utente è
essenziale per le buone prestazioni del DBMS
ß Poiché gli accessi al disco sono frequenti e relativamente
lenti, è importante mantenere la CPU impegnata lavorando
su diversi programmi utente concorrenti.
Il programma di un utente può eseguire molte
operazioni sui dati letti dalla base di dati, ma al
DBMS interessa solo quali dati sono letti/scritti
dalla/sulla base di dati
v Una transazione è la visione astratta del DBMS di un
programma utente: una sequenza di letture e
scritture.
v
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
2
Concorrenza in un DBMS
v
Gli utenti iniziano una transazione, e possono pensare a
ciascuna transazione come fosse eseguita da sola
ß La concorrenza viene ottenuta dal DBMS, che alterna le azioni
(letture/scritture di oggetti del DB) di varie transazioni
ß Ciascuna transazione deve lasciare la base di dati in uno stato
consistente, se il DB era consistente all’inizio della transazione
• Il DBMS garantirà certi VI, a seconda dei VI dichiarati nei comandi
CREATE TABLE
• Oltre a ciò, il DBMS non capisce realmente la semantica dei dati (ad
esempio, non capisce come sia calcolato l’interesse su un conto
bancario)
v
Argomenti: effetto dell’alternanza delle transazioni, e crash
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
3
Atomicità delle transazioni
Una transazione può terminare con successo dopo il
completamento di tutte le sue azioni, oppure può
abortire (o essere abortita dal DBMS) dopo l’esecuzione
di alcune azioni
v Una proprietà molto importante garantita dal DBMS
per tutte le transazioni è che esse sono atomiche. Cioè,
un utente può pensare a una transazione come se
eseguisse tutte le sue azioni in un solo passo, oppure
non ne eseguisse alcuna.
v
ß Il DBMS registra tutte le azioni così da poter annullare le
azioni delle transazioni abortite
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
4
Esempio
•
Consideriamo due transazioni
T1:
T2:
BEGIN A=A+100, B=B-100 END
BEGIN A=1.06*A, B=1.06*B END
• Intuitivamente, la prima transazione trasferisce 100$
dal conto di B al conto di A. La seconda accredita su
entrambi i conti un pagamento di interessi del 6%
• Non c’è garanzia che T1 venga eseguita prima di T2 o
viceversa, se entrambe sono lanciate insieme. Però
l’effetto netto deve essere equivalente al quello delle
due transazioni eseguite serialmente in qualche
ordine
Database
Management Systems 3ed, R. Ramakrishnan and J. Gehrke
5
Esempio (segue)
•
Consideriamo una possibile alternanza (schedule)
T1:
T2:
•
A=1.06*A,
B=B-100
B=1.06*B
Questa va bene. Ma che possiamo dire di
T1:
T2:
•
A=A+100,
A=A+100,
A=1.06*A, B=1.06*B
B=B-100
Il DBMS vede il secondo schedule come
T1:
T2:
R(A), W(A),
R(A), W(A), R(B), W(B)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
R(B), W(B)
6
Scheduling di transazioni
Scheduling seriale: schedule che non alterna le azioni di
transazioni differenti
v Schedule equivalenti: per ogni stato della base di dati,
l’effetto (sull’insieme di oggetti nella base di dati)
dell’esecuzione del primo schedule è identico all’effetto
dell’esecuzione del secondo schedule
v Schedule serializzabile: uno schedule che è equivalente
a qualche esecuzione seriale delle transazioni
(Nota: se ogni transazione conserva la consistenza, ogni
schedule serializzabile conserva la consistenza )
v
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
7
Anomalie con l’esecuzione alternata
•
T1:
T2:
•
Lettura di dati non completati (conflitti RW,
“letture sporche”)
R(A), W(A),
R(A), W(A), C
R(B), W(B), Abort
Letture non ripetibili (conflitti RW)
T1:
T2:
R(A),
R(A), W(A), C
R(A), W(A), C
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
8
Anomalie (segue)
v
T1:
T2:
Sovrascrittura di dati non completati (conflitti
WW)
W(A),
W(A), W(B), C
W(B), C
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
9
Controllo di concorrenza basato sui
lock
v
Protocollo Strict 2PL:
ß ciascuna transazione deve ottenere un lock C (condiviso) su un oggetto
prima di leggere, e un lock E (esclusivo) su un oggetto prima di
scrivere
ß Tutti i lock mantenuti da una transazione sono rilasciati quando la
transazione termina
• Variante (non-strict) 2PL: i lock vengono rilasciati in qualunque
momento, ma non si possono acquisire lock dopo aver rilasciato dei
lock
ß Se una transazione mantiene un lock E su un oggetto, nessuna altra
transazione può ottenere un lock (C o E) su quell’oggetto
v
Lo Strict 2PL permette solo schedule serializzabili
ß Inoltre semplifica le interruzioni delle transazioni
ß Anche il (non strict) 2PL permette solo schedule serializzabili, ma
coinvolge un processo di abort più complesso
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
10
Abortire una transazione
v
v
Se una transazione Ti viene abortita, tutte le sue azioni devono
essere annullate. Non solo, ma se Tj legge un oggetto che è
stato recentemente scritto da Ti, anche Tj deve essere abortita!
La maggior parte dei sistemi evitano queste interruzioni in
cascata rilasciando i lock di una transazione solo al momento
del completamento
ß Se Ti scrive un oggetto, Tj può leggerlo solo dopo che Ti sia terminata
con successo
v
Per annullare le azioni di una transazione abortita, il DBMS
mantiene un log in cui viene registrata ogni scrittura. Questo
meccanismo è usato anche per il ripristino dopo un crash del
sistema: tutte le transazioni attive al momento del crash
vengono abortite quando il sistema ritorna in funzione
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
11
Il log
v
Le azioni seguenti vengono registrate nel log:
ß Ti scrive un oggetto: il vecchio e il nuovo valore
• Il record del log deve andare sul disco prima della pagina
modificata!
ß Ti termina/viene abortita: un record del log indica tale azione
v
v
v
I record del log sono collegati tra loro dall’id della transazione,
così che sia facile annullare una transazione specifica
Il log è spesso duplicato e archiviato su dispositivi di memoria
stabili
Tutte le attività legate ai log (e di fatto tutte le attività collegate
al CC quali lock/unlock, gestione dei deadlock etc) sono gestite
dal DBMS in maniera trasparente
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
12
Recupero dopo un crash
v
Ci sono 3 fasi nell’algoritmo di recupero Aries:
ß Analisi: scansiona il log in avanti (a partire dal più recente checkpoint) per
identificare tutte le transazioni che erano attive, e tutte le pagine
modificate nel buffer pool al momento del crash
ß Riesecuzione: riesegue tutti gli aggiornamenti sulle pagine modificate nel
buffer pool per assicurare che tutti gli aggiornamenti registrati nel log
siano di fatto eseguiti e scritti su disco
ß Annullamento: le scritture di tutte le transazioni che erano attive al
momento del crash sono annullate (ripristinando il valore precedente
l’aggiornamento, che è nel record del log relativo all’aggiornamento), e
lavorando all’indietro nel log (bisogna prendere delle precauzioni per
gestire il caso di un crash che si verifichi durante la procedura di
ripristino!)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
13
Riassunto
v
v
Il controllo di concorrenza e il ripristino sono tra le funzioni
più importanti fornite da un DBMS
Gli utenti non hanno bisogno di preoccuparsi della
concorrenza
ß Il sistema inserisce automaticamente richieste di lock/unlock e gestisce le
azioni di transazioni diverse in modo tale da garantire che l’esecuzione
risultante sia equivalente all’esecuzione delle transazioni una dopo
l’altra in qualche ordine
v
Il Write-Ahead Logging (WAL) viene usato per annullare le
azioni di transazioni abortite e per ripristinare il sistema a uno
stato consistente dopo un crash
ß Stato consistente: si vedono solo gli effetti delle transazioni completate
con successo
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
14