gestione delle transazioni

GESTIONE DELLE
TRANSAZIONI
Transazioni
!
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
Una transazione è la visione astratta del DBMS di
un programma utente
!
una sequenza di letture e scritture.
Giorgio Giacinto 2010
Database
2
Concorrenza in un DBMS
!
Quando gli utenti iniziano una transazione devono
pensarla come se fosse l’unica operazione eseguita
dal DBMS
!
!
La concorrenza viene ottenuta dal DBMS, che alterna le
azioni (letture/scritture) di varie transazioni
Ciascuna transazione deve lasciare la base di dati in
uno stato coerente con i vincoli di integrità, se il DB
era coerente all’inizio della transazione
!
Il DBMS garantirà il rispetto dei VI dichiarati nei comandi
CREATE TABLE, nelle Asserzioni, ecc.
Giorgio Giacinto 2010
Database
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
Una proprietà molto importante garantita dal DBMS
per tutte le transazioni è che esse sono atomiche.
!
!
Un utente può pensare a una transazione come se
! o tutte le sue azioni sono eseguite in un solo passo,
! oppure non ne viene eseguita alcuna.
Il DBMS registra tutte le azioni così da poter
annullare le azioni delle transazioni abortite
Giorgio Giacinto 2010
Database
4
Le proprietà ACID
!
Un DBMS deve assicurare quattro proprietà
delle transazioni
!
Atomicità
Consistenza
Isolamento
Durabilità
!
!
!
Giorgio Giacinto 2010
Database
5
Esempio
!
Consideriamo due transazioni
T1: BEGIN
T2: BEGIN
•
•
A=A+100,
A=1.06*A,
B=B-100
B=1.06*B
END
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 a quello delle due
transazioni eseguite serialmente in qualche ordine
Giorgio Giacinto 2010
Database
6
Esempio (segue)
!
Consideriamo una possibile alternanza (schedule)
T1:
T2:
!
A=A+100,
A=1.06*A,
B=1.06*B
Questa va bene. Ma che possiamo dire di
T1:
T2:
!
B=B-100
A=A+100,
B=B-100
A=1.06*A, B=1.06*B
Il DBMS vede il secondo schedule come
T1:
T2:
R(A), W(A),
R(A), W(A), R(B), W(B)
Giorgio Giacinto 2010
R(B), W(B)
Database
7
Scheduling di transazioni
!
Scheduling seriale
!
!
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
Schedule serializzabile
!
!
schedule che non alterna le azioni di transazioni differenti
uno schedule che è equivalente a qualche esecuzione
seriale delle transazioni
Nota: se ogni transazione conserva la coerenza,
ogni schedule serializzabile conserva la coerenza
Giorgio Giacinto 2010
Database
8
Possibili anomalie
dell’esecuzione concorrente
!
Conflitti WR - “letture sporche”
!
Lettura di dati non completati
T1:
T2:
!
R(A), W(A),
R(B), W(B), Abort
R(A), W(A), Commit
Conflitti RW
!
Letture non ripetibili
T1:
T2:
R(A),
W(A), Commit
R(A), W(A), Commit
Giorgio Giacinto 2010
Database
9
Possibili anomalie
dell’esecuzione concorrente
!
Conflitti WW
!
Sovrascrittura di dati non completati
T1:
T2:
Giorgio Giacinto 2010
W(A),
W(B), C
W(A), W(B), C
Database
10
Protocollo Strict 2PL
Controllo di concorrenza mediante lock
!
Ciascuna transazione deve ottenere
!
!
!
Tutti i lock mantenuti da una transazione sono
rilasciati quando la transazione termina
!
!
!
un lock C (condiviso) su un oggetto prima di leggere
un lock E (esclusivo) su un oggetto prima di scrivere
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 ottiene un lock E su un oggetto,
nessuna altra transazione può ottenere un lock (C o
E) su quell’oggetto
2PL consente solo schedule serializzabili
Giorgio Giacinto 2010
Database
11
Abortire una transazione
!
Se una transazione Ti viene abortita, tutte le sue
azioni devono essere annullate.
!
!
!
Inoltre, se Tj legge un oggetto che è stato recentemente
scritto da Ti, anche Tj deve essere abortita.
La maggior parte dei sistemi evitano questo effetto 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
Per annullare le azioni di una transazione abortita, il
DBMS mantiene un log in cui viene registrata ogni
scrittura.
!
Meccanismo usato anche per il ripristino dopo un crash
Giorgio Giacinto 2010
Database
12
Il log
!
Il log registra le seguenti azioni
!
!
!
!
!
!
Quando Ti scrive un oggetto si registra il vecchio e il nuovo
valore
Quando Ti termina o viene abortita
Il record del log deve essere registrato sul disco prima
della pagina modificata
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 alla concorrenza sono gestite
dal DBMS in maniera trasparente
Giorgio Giacinto 2010
Database
13
Recupero dopo un crash
!
Ci sono 3 fasi nell’algoritmo di recupero Aries
!
!
!
Analisi: scandisce 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
! Viene ripristinato il valore precedente l’aggiornamento
! Gli annullamenti si eseguono scandendo il log all’indietro
! Precauzioni in caso di crash durante il ripristino
Giorgio Giacinto 2010
Database
14