Cap.6 Gestione delle Transazioni Flashcards
Gestione delle transazioni
I sistemi di gestione delle transazioni sono sistemi con grandi basi di dati e centinaia di utenti che eseguono transazioni contemporaneamente. Più
utenti possono accedere al database simultaneamente grazie al concetto di multiprogrammazione, che consente ad un computer di elaborare più
transazioni alla volta. Quando si ha una sola CPU, si elabora un processo alla volta, infatti, l’illusione di avere più programmi che vengono eseguiti
contemporaneamente è fornita dai sistemi operativi multiprogrammati, che eseguono alcune istruzioni da un programma, per poi sospenderlo ed
eseguire altre istruzioni da altri programmi e così via. Quando un programma viene riattivato, esso riparte dal punto in cui era stato sospeso. Su sistemi
monoprocessore, l’esecuzione concorrente dei programmi è quindi intervallata (interleaved), questo ha luogo quando un programma effettua
operazioni di I/O che lasciano la CPU inattiva. Su sistemi multiprocessore l’esecuzione dei programmi avviene realmente in parallelo
Cos’è una transazione?
Una transazione è un insieme di operazioni che accedono al database, viste logicamente come un’istruzione singola ed indivisibile.
Una transazione è un’unità atomica di lavoro che, o è completata nella sua interezza o è integralmente annullata
Quali sono le possibili operazioni di accesso al database?
Read_item(x): legge l’item di nome x in una variabile di programma
Sapendo che l’unità di trasferimento di dati è il blocco:
1. Trovare l’indirizzo del blocco che contiene X.
2. Copiare tale blocco in un buffer in memoria centrale (se tale blocco non è già in un buffer).
3. Copiare l’elemento X dal buffer alla variabile di programma X
Write_item(X): scrive il valore della variabile di programma X nell’elemento X del database. I passi per eseguire un comando Write_item(X) sono:
1. Trovare l’indirizzo del blocco che contiene X.
2. Copiare tale blocco in un buffer in memoria centrale (se tale 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.
Letture fantasma nelle implementazioni sql:
Le letture fantasma si verificano quando:
1. La Transazione A legge tutte le righe che soddisfano una clausola WHERE su una query SQL.
2. La Transazione B inserisce una riga aggiuntiva che soddisfa la clausola WHERE.
3. La Transazione A rivaluta la condizione WHERE e raccoglie la riga aggiuntiv
Quali possono essere i problemi che possono sorgere eseguendo due transazioni concorrentemente? Problemi per cui serve il controllo della concorrenza (es aggiornamento perso etc):
L’esecuzione concorrente di due transazioni all’interno di un sistema di gestione dei database può causare diversi problemi, tra cui:
Aggiornamento perso (Lost Update): Si verifica quando due transazioni modificano lo stesso dato contemporaneamente e uno dei risultati delle modifiche viene sovrascritto dall'altro. Ad esempio, se due transazioni cercano di incrementare lo stesso valore di un contatore, potrebbe verificarsi una situazione in cui l'incremento di una transazione viene sovrascritto dall'incremento dell'altra, causando la perdita di un aggiornamento. Lettura sporca (Dirty Read): Si verifica quando una transazione legge un dato che è stato modificato da un'altra transazione e che potrebbe essere ancora annullato. Ad esempio, se una transazione A modifica un dato e poi fallisce, lasciando il dato in uno stato inconsistente, un'altra transazione B potrebbe leggere tale dato prima che la transazione A venga completata, ottenendo quindi un valore non valido.
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 altro dopo.
Problema delle letture non ripetibili:
Tale problema avviene se una transazione T1 legge due volte lo stesso item, ma tra le due letture una transazione T2 ne ha modificato il valore
Lettura fantasma (Phantom Read): Si verifica quando una transazione esegue una query che restituisce un insieme di record basato su un certo criterio di selezione, ma durante l'elaborazione della transazione stessa, un'altra transazione inserisce o elimina dei record che soddisfano tale criterio, causando così la comparsa di "letture fantasma" di record che sembrano essere apparsi magicamente.
Quali operazioni il manager di recovery tiene traccia? Ciclo di vita delle transazioni
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 database, eseguite come parte di una transazione.
▪ END_TRANSACTION: specifica che le operazioni di READ e WRITE sono finite e marca il limite di fine 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 database devono essere annullati.
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
Quali sono le proprietà delle transizioni?
Le transazioni dovrebbero possedere alcune proprietà (dette ACID properties, dalle loro iniziali):
▪ Atomicità: l’atomicità rappresenta il fatto che una transazione è un’unità indivisibile di esecuzione, cioè vengono resi visibili tutti gli effetti di una transazione oppure la transazione non deve avere alcun effetto sulla base di dati, con un approccio “tutto o niente”. In pratica non è possibile
lasciare la base di dati in uno stato intermedio attraversato durante l’elaborazione della transazione (responsabilità del recovery Subsystem).
▪ Consistency preserving: l’esecuzione di una transazione non violi i vincoli di integrità definiti sulla base di dati. Quando il sistema rileva che una transazione sta violando uno dei vincoli, esso interviene per annullare la transazione o per correggere la violazione del vincolo. Quindi una
transazione deve far passare il database da uno stato consistente ad un altro (responsabilità dei programmatori).
▪ Isolamento: l’isolamento richiede che l’esecuzione di una transazione sia indipendente dalla contemporanea esecuzione di altre transazioni, rendendo invisibili i vari aggiornamenti finché non è committed. In particolare, si richiede che il risultato dell’esecuzione concorrente di un insieme di transazioni sia analogo al risultato che le stesse transazioni otterrebbero qualora ciascuna di esse fosse eseguita da sola (responsabilità del sistema per il controllo della concorrenza).
▪ Durability: la persistenza richiede che l’effetto di una transazione che ha eseguito il commit correttamente non venga più perso. In pratica, una base di dati deve garantire che nessun dato venga perso per nessun motivo (responsabilità del sistema di gestione dell’affidabilità).
Cos’è uno schedule?
Uno schedule è un ordinamento delle operazioni delle transazioni processate in modo interleaved e le operazioni di una transazione devono apparire nello stesso ordine anche nello schedule.
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).
È importante caratterizzare i tipi di schedule in base alla possibilità di effettuare il recovery. Infatti, si vuol garantire che per una transazione committed non è mai necessario il roll-back. I tipi di schedule sono:
▪ Schedule completo, non contiene transazioni attive perché sono tutte committed o aborted;
▪ Schedule stretto, le transazioni non possono né leggere né scrivere un elemento X finché l’ultima transazione che ha scritto X non è completata (commit o abort);
▪ Schedule seriale, per ogni transazione nello schedule, tutte le operazioni delle transazioni sono eseguite senza interleaving.
Uno schedule è detto cascadeless (evitare il roll-back in cascata) se ogni transazione nello schedule legge elementi scritti solo da transazioni committed, in alternativa, si possono avere roll-back in cascata se una transazione non committed legge un dato scritto da una transazione fallita
Quando uno schedule si dice schedule completo?
Uno schedule si dice “schedule completo” quando soddisfa le seguenti condizioni:
Tutte le transazioni previste nell'ambito del sistema sono incluse nello schedule. Ciò significa che ogni transazione inizia e termina correttamente, senza essere interrotta o abbandonata nel mezzo dell'esecuzione. L'ordine di esecuzione delle operazioni all'interno di ogni transazione viene rispettato. In altre parole, le operazioni di una transazione devono essere eseguite in sequenza, senza saltare o riordinare in modo arbitrario. L'ordine di esecuzione delle operazioni tra transazioni diverse viene rispettato. Questo implica che, se un'operazione di una transazione T1 precede un'operazione di una transazione T2 nello schedule, allora la prima operazione deve essere completata prima della seconda operazione. Lo schedule deve rispettare le regole di concorrenza definite dal protocollo di controllo della concorrenza utilizzato, come ad esempio il protocollo Two-Phase Locking (2PL). Queste regole possono includere l'acquisizione e il rilascio corretti dei lock sulle risorse condivise per garantire la serializzabilità delle transazioni.
Un schedule completo assicura che tutte le transazioni siano eseguite correttamente e in modo coerente, rispettando l’ordine delle operazioni sia all’interno di ogni transazione che tra transazioni diverse. Questo contribuisce a mantenere l’integrità dei dati nel sistema e ad evitare anomalie come la perdita di aggiornamenti o la lettura sporca.
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. È importante caratterizzare i tipi di
schedule in base alla possibilità di effettuare il recovery. Infatti, si vuol 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.
Cos’è la serializzabilità? e cos’è uno schedule serializzabile?
La serializzabilità è una proprietà dei sistemi di gestione dei database che assicura che l’esecuzione concorrente di più transazioni abbia lo stesso effetto finale di un’esecuzione seriale delle stesse transazioni. In altre parole, quando un sistema di gestione dei database è serializzabile, il risultato di un insieme di transazioni eseguite contemporaneamente è equivalente al risultato ottenuto eseguendo le stesse transazioni in sequenza, una dopo l’altra.
La serializzabilità è importante per garantire l’integrità dei dati e prevenire situazioni indesiderate come la perdita di aggiornamenti, la lettura sporca o l’interblocco (deadlock) tra le transazioni.
Uno schedule S di n transazioni è serializzabile se è “equivalente” a qualche schedule seriale delle stesse n transazioni
Due schedule sono detti result equivalent (equivalenti) se producono lo stesso stato finale del database, ma non è una definizione accettabile, perché la produzione dello stesso stato può essere accidentale.
Una definizione più appropriata è quella di conflict equivalent, cioè due schedule sono conflict equivalent se l’ordine di ogni coppia di operazioni in conflitto è lo stesso in entrambi gli schedule.
Uno schedule è conflict serializable se è conflict equivalent a qualche schedule seriale. È 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 utilizzano protocolli che
garantiscono che uno schedule sarà serializzabile. Per quanto riguarda l’algoritmo, esso cerca solo le operazioni di read_item e write_item, per
costruire un grafo di precedenza (o grafo di serializzazione).
