BASI DI DATI 2

a.a 2017/2018 Prof.ssa G. Tortora

BASI DI DATI 2

GESTIONE DELLE TRANSAZIONI

Concetto di transazione

¨

La transazione fornisce un meccanismo per

descrivere le unità logiche di elaborazione delle basi di dati.

¨

I sistemi di gestione delle transazioni sono

sistemi con grandi basi di dati e centinaia di utenti che eseguono transazioni contemporaneamente.

¤

Esempi: sistemi di prenotazione, bancari, per la

gestione delle carte di credito, …

Introduzione alle Transazioni

DBMS Single-User Vs. Multi-User

¨

È possibile classificare i database system in base al numero di utenti che possono utilizzare il

sistema in modo concorrente.

¨

Un DBMS è single-user (monoutente) se al più un utente per volta può usare il sistema.

¨

Un DBMS è multi-user se più utenti possono

usare il sistema concorrentemente.

La multiprogrammazione

¨

Più utenti possono accedere al database simultaneamente grazie al concetto di

multiprogrammazione, che consente ad un computer di elaborare più programmi o

transazioni simultaneamente.

I sistemi multiprogrammati

¨

Quando si ha una sola CPU, necessariamente si elabora un processo alla volta.

¨

L’illusione di avere più programmi che eseguono contemporaneamente è fornita dai sistemi

operativi multiprogrammati.

¨

Tali sistemi eseguono alcune istruzioni da un programma, poi lo sospendono e ne eseguono alcune da altri programmi, e così via.

¨

Un programma è riattivato dal punto in cui era

stato sospeso.

L’interleaving di processi

¨

Su sistemi monoprocessore, l'esecuzione

concorrente dei programmi è quindi intervallata (interleaved):

¤

L'interleaving ha luogo in genere quando un programma effettua un I/O

(operazione che lascia la CPU inattiva).

¨

Su sistemi multiprocessore, invece, l’esecuzione

dei programmi avviene realmente in parallelo.

Esempi di multiprogrammazione

Due processi interleaved su un sistema con una CPU.

Due processi in parallelo su

un sistema con due CPU.

Le Transazioni

¨

Informalmente una transazione è un insieme di operazioni che accedono al db, viste logicamente come un’istruzione singola ed indivisibile.

¨

Per mostrare la gestione delle transazioni,

useremo una visione semplificata di un database system:

¤

Un db è visto come una collezione di data item, ognuno con un nome.

¤

La dimensione del data item è detta granularità: può

essere un singolo campo di un record, così come un

intero blocco di un disco.

Operazioni possibili

¨

Con tale semplificazione, le possibili operazioni di accesso al db che una transazione può effettuare sono:

¤

Read_item(X): legge l’item di nome X in una variabile di programma. Per semplicità assumiamo che anche la variabile si chiami X.

¤

Write_item(X): scrive il valore della variabile di

programma X nell'elemento X del database.

La Read_item(X)

¨

Sappiamo che l'unità di trasferimento di dati è il blocco.

¨

Passi per eseguire un comando Read_item(X):

1.

Trovare l'indirizzo del blocco che contiene X.

2.

Copiare tale blocco in un buffer in memoria centrale (se il blocco non è già in un buffer).

3.

Copiare l'elemento X dal buffer alla variabile di

programma X.

La Write_item(X)

¨

Passi per eseguire un comando Write_item(X)

1.

Trovare l'indirizzo del blocco che contiene X.

2.

Copiare tale blocco in un buffer in memoria centrale (se il blocco non è già in un buffer).

3.

Copiare l'elemento X dalla variabile di programma di nome X nella sua locazione nel buffer.

4.

Memorizzare il blocco aggiornato dal buffer al disco.

Controllo della concorrenza

¨

Il controllo della concorrenza e dei meccanismi di recovery riguardano principalmente i comandi di accesso al db in una transazione.

¨

Transazioni inviate da più utenti, che possono accedere e aggiornare gli elementi del db, sono eseguite concorrentemente.

¨

Se l'esecuzione concorrente non è controllata, si possono avere problemi di database

inconsistente.

Perché è necessario il controllo

della concorrenza

Esempio di problemi con transazioni

¨

Supponiamo di avere un db per la prenotazione di posti in aereo, in cui è memorizzato un record per ogni volo.

¨

Supponiamo di avere due transazioni, T

e T

:

¤

La transazione T

cancella N prenotazioni da un volo il cui numero di posti occupati è memorizzato nell’item

del db di nome X, e riserva lo stesso numero su un altro volo il cui numero di posti occupati è memorizzato

nell’item di nome Y.

¤

T

prenota M posti sul primo volo referenziato nella

transazione T

.

Esempio di problemi con transazioni (2)

¨

Vediamo i possibili problemi che possono sorgere eseguendo T

e T

concorrentemente …

n

Le due transazioni per la gestione dei posti:

Aggiornamento perso

¨

Problema dell’aggiornamento perso:

¤

Supponiamo che T

e T

siano avviate insieme e che le loro operazioni siano interleaved dal sistema operativo nel modo seguente:

Il valore finale di X è

scorretto perché T₂ legge il valore di X prima che T₁ lo salvi: l’aggiornamento di T₁ è quindi perso.

Tempo

Aggiornamento temporaneo

¨

Problema dell’aggiornamento temporaneo (o lettura sporca):

¤

Una transazione aggiorna un elemento ma poi fallisce per qualche motivo.

¤

L’elemento aggiornato è però letto da un’altra

transazione prima che esso sia riportato al suo

valore originario.

Aggiornamento temporaneo (2)

¨

Il valore di X letto da T

è detto dato sporco, perché è stato creato da una transazione annullata.

La transazione T₁ fallisce e deve riportare X al suo valore originario;

nel frattempo T₂ ha letto il valore

‘temporaneamente’ scorretto di X.

Totalizzazione scorretta

¨

Problema della totalizzazione scorretta:

¤

Se una transazione sta calcolando una funzione di aggregazione su un certo insieme di record,

mentre altre transazioni stanno aggiornando alcuni

di tali record, la funzione può calcolare alcuni valori

prima dell'aggiornamento ed altri dopo.

Totalizzazione scorretta (2)

¨

Una transazione T

sta calcolando il numero

totale di prenotazioni su tutti i voli mentre T

è in esecuzione:

Il risultato di T₃ è sbagliato, poiché T₃ legge il valore di X dopo che sono stati sottratti N posti, e prima che gli stessi siano sommati ad Y.

Letture non ripetibili

¨

Problema delle letture non ripetibili:

¤

Avviene se una transazione T

legge due volte lo

stesso item, ma tra le due letture una transazione T

ne ha modificato il valore.

¤

Esempio: durante una prenotazione di posti aerei, un cliente chiede informazioni su più voli.

Quando il cliente decide, la transazione deve rileggere il numero di posti disponibili sul volo scelto per

completare la prenotazione, ma potrebbe non trovare

più la stessa disponibilità.

Perché sono necessarie

le tecniche di recovery

Necessità del Recovery

¨

Quando viene inoltrata una transazione, il sistema deve far sì che:

¤

Tutte le operazioni siano completate con successo ed il loro effetto sia registrato permanentemente nel db, oppure

¤

la transazione annullata non abbia effetti né sul db

né su qualunque altra transazione.

Tipi di fallimento (Failure)

¨

Le failure vengono in genere suddivise in

fallimenti di transazione, di sistema e di media.

¨

Possibili ragioni di una failure:

1.

Un crash di sistema durante l'esecuzione della transazione.

2.

Errore di transazione o di sistema

n Esempi: overflow, divisione per zero, valori errati di parametri, …

Tipi di fallimento (2)

3.

Errori locali o condizione eccezionali rilevati dalla transazione.

n Esempio: i dati per la transazione possono non essere trovati o essere non validi, tipo un ABORT programmato a fronte di richiesta di un prelievo da un fondo scoperto.

4.

Controllo della concorrenza.

n Il metodo di controllo della concorrenza può decidere di abortire la transazione perché viola la serializzabilità o perché varie transazioni sono in deadlock.

Tipi di fallimento (3)

5.

Fallimento di disco.

n Alcuni blocchi di disco possono perdere i dati per un

malfunzionamento in lettura i scrittura, o a causa di un crash della testina del disco.

6.

Problemi fisici e catastrofi

n Esempi: fuoco, sabotaggio, furto, caduta di tensione, errato montaggio di nastro da parte dell’operatore, …

¨

I problemi 1-4 sono i più frequenti, ed è più

facile effettuarne il recovery.

Concetti sulle Transazioni

Operazioni delle transazioni

¨

Una transazione è un’unità atomica di lavoro che o è completata nella sua interezza o è

integralmente annullata.

¨

Per motivi di recovery, il sistema deve tenere

traccia dell’inizio e della fine o dell’abort di ogni

transazione.

Operazioni per le transazioni (2)

¨

Il manager di recovery tiene quindi traccia delle seguenti operazioni:

¤ BEGIN_TRANSACTION: marca l’inizio dell’esecuzione della transazione.

¤ READ o WRITE: specifica operazioni di lettura o scrittura sul db, eseguite come parte di una transazione.

¤ END_TRANSACTION: specifica che le operazioni di READ e WRITE sono finite e marca il limite di fine di esecuzione della transazione.

¤ COMMIT_TRANSACTION: segnala la fine con successo della transazione, in modo che qualsiasi cambiamento può essere reso permanente, senza possibilità di annullarlo.

¤ ROLL-BACK (o ABORT): segnala che la transazione è

terminata senza successo e tutti i cambiamenti o effetti nel db devono essere annullati.

Operazioni per le transazioni (3)

¨

Operazioni addizionali:

¤

UNDO: simile al roll-back, eccetto che si applica ad un’operazione singola piuttosto che a una intera

transazione.

¤

REDO: specifica che certe operazioni devono essere

ripetute.

Stati di una transazione

¨

Si può usare un diagramma degli stati per evidenziare come evolve lo stato di una transazione:

In questo stato, alcune tecniche di recovery richiedono di effettuare dei controlli per garantire che la transazione non influisca con altre.

Il System Log

¨

Per effettuare il recovery di transazioni abortite, il sistema mantiene un log (o journal) per tenere traccia delle operazioni che modificano il

database.

¨

Il system log contiene quindi informazioni su tutte

le transazioni che modificano i valori degli item

del database.

Le entry del System Log

¨

Il log è strutturato come una lista di record.

¨

In ogni record è memorizzato un ID univoco della transazione T, generato in automatico dal

sistema.

¨

Tipi di entry possibili nel log:

¤

[start_transaction, T]

la transazione T ha iniziato la sua esecuzione.

¤

[write_item, T, X, old_value, new_value]

la transazione T ha cambiato il valore dell’item X da

old_value a new_value.

Le entry del System Log (2)

¤

[read_item, T, X]

La transazione T ha letto l’item X.

¤

[commit, T]

La transazione T è terminata con successo e le modifiche possono essere memorizzate in modo permanente.

¤

[abort, T]

La transazione T è fallita.

Scrittura forzata del log

¨

Il file di log deve essere tenuto su disco.

¨

Aggiornare il log implica copiare il blocco dal

disco al buffer in memoria, aggiornare il buffer e riscrivere il buffer su disco.

¨

Di fronte ad una failure, solo le entry su disco vengono usate nel processo di recovery.

¨

Poiché un blocco viene tenuto in memoria finché non è pieno, prima che una transazione

raggiunga il punto di commit, ogni parte del log in

memoria deve essere scritta (scrittura forzata o

force writing).

Proprietà delle transazioni

Proprietà delle transazioni

¨

Le transazioni dovrebbero possedere alcune proprietà (dette ACID properties, dalle loro iniziali):

¤

Atomicità: una transazione è un’unità atomica di

elaborazione da eseguire o completamente o per niente (responsabilità del recovery subsystem).

¤

Consistency preserving: una transazione deve far

passare il database da uno stato consistente ad un

altro (responsabilità dei programmatori).

Proprietà delle transazioni (2)

¤

Isolation: Una transazione non deve rendere visibili i suoi aggiornamenti ad altre transazioni finché non è committed (responsabilità del sistema per il controllo della concorrenza)

¤

Durability: Se una transazione cambia il database, e il cambiamento è committed, queste modifiche non

devono essere perse a causa di fallimenti successivi

(responsabilità del sistema di gestione dell’affidabilità)

Gli Schedule

Lo Schedule

¨

Informalmente, uno schedule è l’ordine in cui sono eseguite le operazioni di più transazioni processate in modo interleaved.

¨

Formalmente, uno schedule (o storia) S di n

transazioni T

, T

, …, T

è un ordinamento delle operazioni delle transazioni, soggetto al vincolo che per ogni transazione T

che partecipa in S, le operazioni in T

in S devono apparire nello stesso ordine di apparizione in T

.

¤

Supponiamo che l’ordinamento delle operazioni in S sia

totale.

Lo Schedule: Esempio

¨

Lo schedule per queste transazioni, che chiamiamo S

, può essere espresso come:

S

: r

(X); r

(X); w

(X); r

(Y); w

(X); w

(Y)

Tempo

Lo Schedule: Esempio 2

¨

Lo schedule S

per queste transazioni può essere espresso come:

S

: r

(X); w

(X); r

(X); w

(X); r

(Y); a

La transazione T₁ fallisce.

Conflitto di operazioni

¨

Due operazioni in uno schedule sono in conflitto se:

1.

appartengono a differenti transazioni,

2.

accedono allo stesso elemento X,

3.

almeno una delle due operazioni è una

write_item(X).

Conflitto di operazioni: Esempio

¨

In verde le coppie che non generano conflitti.

¨

In rosso le coppie che generano conflitti,

S

’: r

(X); r

(X); w

(X); r

(Y); w

(X); c

; w

(Y); c

Schedule completo

¨

Uno schedule S di n transazioni T

, T

, …, T

è uno schedule completo se valgono le seguenti condizioni:

1.

Le operazioni in S sono esattamente quelle in

T

, T

, …, T

, incluso un’operazione di commit o di abort come ultima operazione di ogni transazione in S.

2.

Per ogni coppia di operazioni dalla stessa transazione T

, il loro ordine di occorrenza in S è lo stesso che in T

.

3.

Per ogni coppia di operazioni in conflitto, una deve

occorrere prima dell’altra nello schedule.

Proiezione committed

¨

Uno schedule completo non contiene transazioni attive, perché sono tutte committed o aborted.

¨

Dato uno schedule S, si definisce proiezione

committed C(S), uno schedule che contiene solo

le operazioni in S che appartengono a transazioni

committed.

Caratterizzazione di schedule

¨

È importante caratterizzare i tipi di schedule in base alla possibilità di effettuare recovery.

¨

Vorremmo garantire che:

Per una transazione committed non è mai necessario il roll-back.

¤

Uno schedule con tale proprietà è detto recoverable.

¨

Alternativamente, uno schedule S è detto

recoverable se nessuna transazione T in S fa un commit, finché tutte le transazioni T’, che hanno scritto un elemento letto da T, hanno fatto un

commit.

Schedule recoverable: Esempio

¨

Sia S

’:

r

(X); r

(X); w

(X); r

(Y); w

(X); c

; w

(Y); c

¤

S

’ è recoverabile, ma soffre del problema dell’aggiornamento perso.

¨

Sia S

:

r

(X); w

(X); r

(X); r

(Y); w

(X); c

; a

¤

S

non è recoverable perché T

legge X da T

e poi fa il commit prima di T

. Se T

abortisce dopo c

, allora il

valore di X che T

legge non è più valido e T

deve

essere abortito dopo aver fatto commit.

Schedule recoverable: Esempio (2)

¨

Se modifichiamo S

da:

r

(X); w

(X); r

(X); r

(Y); w

(X); c

; a

a:

r

(X); w

(X); r

(X); r

(Y); w

(X); w

(Y); c

; c

S

diviene uno schedule recoverable.

Roll-Back in cascata

¨

Negli schedule recoverable nessuna transazione commited ha necessità di

roll-back.

¨

Si possono però avere roll-back in cascata se una transazione non committed legge un dato scritto da una transazione fallita.

¨

Uno schedule è detto evitare il roll-back in

cascata se ogni transazione nello schedule legge

elementi scritti solo da transazioni committed.

Cascadeless Schedule: Esempio

¨

Sia S

:

r

(X); w

(X); r

(X); r

(Y); w

(Y); w

(Y); c

; c

¨

S

non è cascadeless: T

legge X scritto da T

prima che T

raggiunga il commit o l’abort:

S’

:

r

(X); w

(X); r

(Y); w

(Y); c

; r

(X); w

(X); c

Schedule stretti

¨

Uno schedule è detto stretto se le transazioni non possono né leggere né scrivere un elemento X

finché l’ultima transazione che ha scritto X non è completata (con commit o abort).

¨

Schedule stretti semplificano il processo di

recovery poiché occorre solo ripristinare la before

image (old_value) di un dato X.

Schedule stretti: Esempio

¨

Sia S

:

w

(X,5); w

(X,8); a

¨

Supponiamo che inizialmente sia X = 9.

¨

S

è cascadeless ma non stretto.

¤

Se T

fallisce, la procedura di recovery ripristina il

valore di X a 9, anche se è stato modificato da T

.

Serializzabilità di schedule

Caratterizzazione di schedule

¨

Oltre a caratterizzare gli schedule in base alla possibilità di recovery, vorremmo classificarli

anche in base al loro comportamento in ambiente concorrente.

¨

Uno schedule è seriale se per ogni transazione T nello schedule, tutte le operazioni di T sono

eseguite senza interleaving.

Altrimenti è non seriale.

Schedules seriali: Esempio

¨

I due possibili casi di schedule seriali con due transazioni T

e T

:

a)

T

esegue prima di T

b)

T

esegue dopo T

a) b)

Problemi con gli schedule seriali

¨

Limitano la concorrenza o le operazioni di interleaving:

¤

Se una transazione aspetta una operazione di I/O, non si può allocare la CPU ad un’altra transazione.

¤

Se una transazione T dura a lungo, le altre transazioni devono aspettare che finisca.

¨

Gli schedule seriali, in pratica, sono inaccettabili.

Problemi con gli schedule non seriali

¨

Gli schedule non seriali possono dare i problemi dell’aggiornamento perso, dell’aggiornamento temporaneo, della somma scorretta, etc.

Tempo

L’effetto di T

su X è

perso, sovrascritto da

T

.

Problemi con gli schedule non seriali (2)

¨

Esistono degli schedule non seriali che danno risultati corretti.

¨

Domande:

¤

Quali schedule non seriali danno sempre un risultato corretto?

¤

Quali, invece, danno sempre un risultato scorretto?

Schedules serializzabili

¨

Uno schedule S di n transazioni è serializzabile se è “equivalente” a qualche schedule seriale delle stesse n transazioni.

¤

Dati n schedules, abbiamo n! possibili seriali.

Equivalenza tra schedule

¨

Quando due schedule possono essere detti

“equivalenti”?

¨

Due schedule sono detti result equivalent se producono lo stesso stato finale del db.

¤

Non è una definizione accettabile: la produzione dello stesso stato può essere accidentale.

¨ I due schedules sono result equivalent solo se X = 100.

Equivalenza tra schedules (2)

¨

Una definizione più appropriata è quella di conflict equivalent:

¤

Due schedule sono conflict equivalent se l’ordine di ogni coppia di operazioni in conflitto è lo stesso in entrambi gli schedule.

¨

Esempio: in S

sono presenti r

(X); w

(X) e nello schedule S2 sono in ordine inverso, w

(X); r

(X).

Il valore r

(X) può essere differente nei due

schedule.

La Conflict serializzabilità

¨

Uno schedule è conflict serializzable se è conflict equivalent a qualche schedule seriale S’.

¨

È possibile determinare, per mezzo di un

semplice algoritmo, la conflict serializzabilità di uno schedule.

¤

Molti metodi per il controllo della concorrenza non testano la serializzabilità;

piuttosto usano protocolli che garantiscono che uno

schedule sarà serializzabile.

Conflict serializzabilità: Esempio

¨

Lo schedule D è conflict serializzabile.

Tempo

Schedule D

Read_Item(X) legge il valore di X scritto da T₁.

Algoritmo per la serializzabilità

¨

L’algoritmo cerca solo le operazioni di read_item e write_item, per costruire un grafo di precedenza (o grafo di serializzazione).

¨

Un grafo di precedenza è un grafo diretto G=(N, E), con un insieme di nodi

N={T

, T

, …, T

} ed un insieme di archi diretti E={e

, e

, …, e

}.

¨

Ogni arco è della forma (T

à T

), con

1£j, k£n, ed è creato se un operazione in T

appare nello schedule prima di qualche

operazione in conflitto in T

.

Algoritmo per la serializzabilità (2)

¨

Algoritmo 1:

1. Per ogni transazione T_i nello schedule S, creare un nodo T_i nel grafo;

2. Per ogni caso in S dove T_j esegue una read_item(X) dopo che T_i esegue una write_item(X), creare un arco (T_i à T_j) nel grafo;

3. Per ogni caso in S dove T_j esegue una write_item(X) dopo che T_i esegue una read_item(X), creare un arco (T_i à T_j) nel grafo;

4. Per ogni caso in S dove T_j esegue una write_item(X) dopo che T_i esegue una write_item(X), creare un arco (T_i à T_j) nel grafo;

5. Lo schedule è serializzabile se e solo se il grafo non contiene cicli.

Esempio

¨

Uno schedule seriale con due transazioni, ed il

relativo grafo di precedenza.

Esempio 2

¨

Uno schedule non seriale con due transazioni, ed il relativo grafo di precedenza che ne

evidenzia la non serializzabilità.

Determinazione dello schedule seriale equivalente

¨

Se non ci sono cicli nel grafo di precedenza

relativo ad uno schedule S possiamo creare uno schedule seriale equivalente S’ ordinando le

transazioni che partecipano allo schedule come segue:

¤

Se esiste un arco fra T

e T

; T

deve apparire prima

di T

nello schedule seriale equivalente.

Esempio di costruzione di uno schedule seriale

Tempo

Supporto alle transazioni in SQL

Supporto di SQL alle transazioni

¨

Il concetto di transazione in SQL è simile a quanto visto finora: una transazione è una singola unità logica di lavoro con la proprietà dell’atomicità.

¨

Di default, in SQL ogni singola istruzione è una transazione.

¨

Non esiste uno statement di Begin_Transaction, poiché l’inizio di una transazione viene

determinato implicitamente.

¨

Deve esserne però esplicitata la fine, con le

istruzioni COMMIT o ROLLBACK.

Supporto di SQL alle transazioni (2)

¨

Ogni transazione in SQL ha tre caratteristiche, specificate per mezzo dell’istruzione SET

TRANSACTION che inizia una transazione:

¤

Modalità di accesso.

Specifica se l’accesso ai dati è in sola lettura o in lettura/scrittura.

¤

Dimensione dell’Area Diagnostica.

Specifica lo spazio da usare per informazioni all’utente sull’esecuzione delle transazioni.

¤

Isolation Level.

Specifica la politica di gestione delle transazioni

concorrenti.

Utilizzo del Commit

¨

È molto importante utilizzare due commit (uno prima e uno dopo).

¨

SET TRANSACTION deve essere la prima istruzione SQL di una transazione.

¤

Il COMMIT appena prima assicura che ciò sia vero.

¤

Il COMMIT alla fine rilascia le risorse possedute

dalla transazione.

Modalità di accesso

¨

La modalità di accesso può essere specificata come READ ONLY o READ WRITE (default).

¤

La modalità READ WRITE permette l’esecuzione di comandi di aggiornamento, inserimento,

cancellazione e creazione.

¤

La modalità READ ONLY serve unicamente per il

recupero di dati.

Modalità di accesso (2)

¨

Alcune transazioni effettuano istruzioni di SELECT su diverse tabelle e dovranno vedere dati coerenti, dati che si riferiscono allo stesso istante di tempo.

¨

SET TRANSACTION READ ONLY

¤

Specifica questo meccanismo più protetto di gestione dei dati.

¨

Nessun comando può modificare i dati di un’area su cui vengono effettuate operazioni di SELECT

attraverso questo tipo di transazioni.

Dimensione dell’area di diagnosi

¨

L’opzione dimensione dell’area di diagnosi

DIAGNOSTIC SIZE n specifica un valore intero n, che indica il numero di condizioni che possono essere mantenute contemporaneamente nell’area di diagnosi.

¨

Tali condizioni forniscono informazioni di

feedback (errori o eccezioni) riguardo i comandi

SQL eseguiti più di recente.

Livello di isolamento

¨

L’opzione livello di isolamento è specificata usando l’istruzione

ISOLATION LEVEL <isolamento>

¨

I possibili valori sono:

¤

READ UNCOMMITTED

¤

READ COMMITTED

¤

REPETEABLE READ

¤

SERIALIZABLE

¨

SERIALIZABLE è il livello predefinito.

Problemi con transazioni in SQL

¨

Oltre alle già viste violazioni di “letture sporche” e

“letture non ripetibili”, usando SQL può sorgere il problema delle “letture fantasma”.

¤

Esempio: Supponiamo che una transazione T

legga una serie di righe basate su una condizione di WHERE.

Se una transazione T

aggiunge dei valori che

soddisfano la condizione di WHERE, una riesecuzione

di T

vedrà delle righe nuove (fantasma), non presenti

in precedenza.

Violazioni basate sui livelli di isolamento definiti in SQL

Tipo di violazione

Livello di isolamento Lettura sporca Lettura non ripetibile Fantasma

READ UNCOMMITTED SI SI SI

READ COMMITTED NO SI SI

REPEATABLE READ NO NO SI

SERIALIZABLE NO NO NO

Transazione SQL: Esempio

EXEC SQL WHENEVER SQLERROR GOTO UNDO;

EXEC SQL SET TRANSACTION READ WRITE

DIAGNOSTICS SIZE 5

ISOLATION LEVEL SERIALIZABLE;

EXEC SQL INSERT INTO EMPLOYEE (FNAME, LNAME,

SSN, DNO, SALARY) VALUES ('Robert','Smith','991004321',2,35000);

EXEC SQL UPDATE EMPLOYEE

SET SALARY = SALARY * 1.1 WHERE DNO = 2;

EXEC SQL COMMIT;

GOTO THE_END;

UNDO: EXEC SQL ROLLBACK;

THE_END: ...

Transazione SQL: Esempio (2)

¨

La transazione produce prima l’inserimento di una nuova riga nella tabella EMPLOYEE e

successivamente esegure l’aggiornamento dello stipendio di tutti gli impiegati che lavorano nel

reparto 2.

¨

In caso di errore in una qualsiasi istruzione SQL, l’intera transazione viene annullata (rollback).

¤

Ogni valore di stipendio aggiornato viene

ripristinato al suo valore precedente e la nuova riga

viene rimossa.