Deck 2 Flashcards
Elencare le proprietà ACIDe delle transazioni
Atomicità: la transazione deve essere trattata come una struttura atomica.
Consistenza: L’esecuzione delle transazione non deve violare i vincoli di integrità
Isolamento: l’esecuzione di una transazione deve essere indipendente da quella di altre transazioni.
Durabilità: Gli effetti di una transazione devono essere permanenti dopo il Commit.
Memoria Stabile, cos’è e a cosa serve.
La Memoria Stabile è una memoria resistene ai guasti, è un’astrazione poichè nessuna memoria è senza peccato. Viene utilizzata per la memorizzazione del LOG utile per effettuare UNDO e REDO.
Write-Ahead-Log e Commit-Precedenza
Write Ahead Log: La parte BEFORE STATE dei Log deve essere scritta prima di effettuare l’operazione sul DB (consente il ripristino in caso di guasto)
Commit precedenza: La parte AFTER STATE dei record di Log deve essere scritta nel Log prima di effettuare il Commit (permette di fare i REDO delle scritture)
Livelli di isolamento SQL2
Per ogni transazione si può indicare un livello di isolamento:
1) Read Uncommited: nessun vincolo
2)Read Committed: chiede Lock Condivisi per Read
3)Repetable read: chiede 2PL stretto anche per Read
4)Serializable: Chiede 2PL stretto, usa lock di predicato
Checkpoint e DUMP
Il Checkpoint è un’operazione di sistema svolta dal Gestore dell’Affidabilità, Registra nel LOG le transazioni attive, aggiorna la memoria secondaria circa le Transazioni Completate. Quando eseguito, viene sospesa l’accettazione di operazioni di scrittura, commit, abort
Il DUMP è un’operazione di copia del DB memorizzata su Memoria Stabile (Nastro), serve per il BACKUP.
Anomalie delle transazioni concorrenti
-Perdita di Aggiornamenti: Modifiche di T sovrascritte
-Lettura Sporca: T legge risultato intermedio di un abort
-Letture inconsistenti: T legge oggetti sotto modifica
-Aggiornamento Fantasma-
-Inserimento Fantasma
Protocollo Two Phase Commit senza Guasti
é un protocollo per la gestione dei Commit o Abort globale di una Transazione distribuita. Suddiviso in due fasi:
FASE 1
-Il Transaction Manager scrive PREPARE nel Log e lo
invia a tutti i Resource Manager del DB distribuito e
setta un Timeout per le risposte.
(Prepare contiene gli ID dei RM coinvolti)
-Ogni RM se in stato affidabile scrive READY su Log e invia al TM altrimenti invia NON READY e Abortisce
-il TM raccoglie tutti i messaggi di risosta, se sono tutti READY, il TM scrive un GLOBAL COMMIT e invia.
Se c’è anche un solo NON READY, TM scrive GLOBAL ABORT e invia.
(Se scade il Timeout per qualcuno fa Global Abort)
FASE2
Quando il TM Global Committa o Aborta, setta un Timeout di risposta. Ogni RM, ricevuta la decisione del TM, scrive nel proprio Log , invia un ACK al TM ed esegue la Transazione.
Il TM riceve gli ACK, se arrivano tutti prima del Timeout scrive COMPLETE sul Log e termina
Se il timeout scade per qualche RM, Il TM ripete la FASE2.
Protocollo Two Phase Commit con Guasti
Se durante l’attesa della risposta globale del TM di un RM in stato Ready, succede un guasto, si avvia una fase di ripristino.
Caduta RM: Ripresa a Caldo
Cadura TM: Ripresa a Caldo
Schedule, Schedule Seriale, Schedule Serializzabile, Commit Proiezione
Schedule: sequenza di operazioni I/O di Transazioni concorrenti riportante in ordine cronologico
Schedule Seriale: Per ogni operazione di Ti, tutte le operazioni di Ti sono eseguite consecutivamente
Schedule Serializzabile: Schedule non Seriale che produce lo stesso risultato di qualche schedule seriale delle stesse T
Commit Proiezione: si considerano solo tutte le operazioni che non producono Abort
in ambito di Schedule Serializzabile: 2PL Locking
Il Two-Phase Locking (TPL) è un algoritmo di controllo di concorrenza utilizzato per garantire la serializzabilità di uno schedule di transazioni in un sistema di gestione dei database. Il TPL è uno dei modi più comuni per implementare la serializzabilità in un sistema di gestione dei database.
Il TPL è composto da due fasi: una fase di acquisizione dei lock (Growing Phase) e una fase di rilascio dei lock (Shrinking Phase). Durante la fase di acquisizione dei lock, una transazione acquisisce i lock necessari per accedere ai dati che deve leggere o modificare. Durante la fase di rilascio dei lock, una transazione rilascia i lock che non è più interessata ad utilizzare.
Il TPL garantisce che due transazioni non possano accedere contemporaneamente allo stesso dato, a meno che entrambe le transazioni non stiano solo leggendo il dato (cioè utilizzando un lock in sola lettura). In caso contrario, una delle transazioni deve attendere che l’altra transazione abbia rilasciato il lock.
View equivalenza e Conflict equivalenza
La view equivalence si riferisce alla proprietà per cui due viste (cioè delle tabelle virtuali create a partire da una query SQL) rappresentano lo stesso insieme di dati. In altre parole, due viste sono equivalenti se la loro unione (U) genera una tabella che contiene gli stessi dati della tabella originale, anche se possono essere presentati in modo diverso o utilizzare nomi diversi per le colonne.
La conflict equivalence si riferisce alla proprietà per cui due viste sono equivalenti, ma hanno schemi di tabelle diversi. Ciò significa che hanno lo stesso insieme di dati ma le relazioni tra le tabelle e le colonne sono differenti.
In ambito di Schedule Serializzabile: VSR, CSR
VSR: La View serializzabilità (o View Serializability) si riferisce alla proprietà di uno schedule di transazioni per cui, per ogni transazione, l’insieme di righe che la transazione legge nel database è lo stesso di quello che leggerebbe se la transazione fosse stata eseguita in modo seriale rispetto alle altre transazioni.
CSR: La Conflict serializzabilità (o Conflict Serializability) si riferisce alla proprietà di uno schedule di transazioni per cui, per ogni transazione, l’insieme di righe che la transazione legge e modifica nel database è lo stesso di quello che leggerebbe e modificherebbe se la transazione fosse stata eseguita in modo seriale rispetto alle altre transazioni.
2PL STRETTO, 2PL CONSERVATIVO, TIMESTAMP
Il 2PL Stretto: Richiede il lock esclusivo su una risorsa prima di poter scrivere su essa. Dopo aver rilasciato il lock, una transazione non può richiederne altri. la Transazione rilascia il lock solo se ha deciso se fare commit o abort.
Il 2PL Conservativo necessita che una T, prima di iniziare le operazioni, acquisisca il lock su tutte le risorse utilizzate da T. Ciò garantisce che nessuna transazione possa accedere a una risorsa mentre è ancora in uso da un’altra transazione, il che riduce la possibilità di conflitti tra transazioni.
Timestamp: è un valore univoco utilizzato per ordinare le transazioni in base al loro ordine di esecuzione. Viene assegnata ad ogni T quando questa viene avviata e indica l’istante di tempo in cui la transazione è iniziata. consente di gestire la concorrenza tra transazioni.
TS monoversione ma non Multiversione e Ts Multiversione ma non Monoversione
Non può esistere un timestamp monoversione ma non multiversione.
Uno schedule Multiversione ma non Monoversione esiste: RTM=0 WTM=0 e Write(x,4) Read(x,3)
Prevenzione Deadlock basata su TimeStamp (Preemptive e non Preemptive)
Il Deadlock viene evitato uccidendo una delle transazioni che creerebbero cicli nel grafo di attesa.
Preemptive:(Ti>Tj)viene uccisa la transazione che possiede la risorsa
Non Preemptive: (Ti
