Transazioni. Capitolo 13. Scrittura immediata e scrittura differita. Concorrenza in un DBMS. Una transazione. Gestione delle transazioni

Transcript

1 Capitolo 13 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, è unaè sequenza importante mantenere di azioni la CPU impegnata sulla base lavorando di dati su che diversi programmi utente concorrenti. Il programma di un utente può eseguire molte viene eseguita del tutto o operazioni sui dati letti dalla base di dati, ma al DBMS interessa solo quali dati sono letti/scritti dalla/sulla base di dati non viene eseguita per niente Una transazione è la visione astratta del DBMS di un programma utente: una sequenza di letture e scritture (qualunque singola esecuzione di un programma utente) Una transazione Scrittura immediata e scrittura differita Concorrenza in un DBMS 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 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) Argomenti: effetto dell alternanza delle transazioni, e crash modalita di implementazione della proprieta transazionale Scrittura immediata sul DB con possibilità di disfare ( undoing ) quanto già fatto, annullando gli effetti delle scritture. Transazioni efficienti, ma gestione più complessa del giornale delle modifiche (database log file). Scrittura differita sulla base di dati. Si dà l illusione che le scritture avvengano sul DB, ma in realtà esse avvengono in un area temporanea e solo alla fine riportate sul DB. 1

2 Rolling back e transazione abortita Quando si verifica un fallimento vengono intraprese opportune azioni di rolling back ( rotolamento all indietro ) che annullano gli effetti parziali che potrebbero essere stati prodotti; si dice allora che la transazione è stata abortita (aborted). Cause di fallimento di una transazione 1. Errori logici: immissione di dati errati, errori runtime tradizionali, violazioni di vincoli di integrità 2. Fallimenti voluti: il programmatore, per una qualche ragione, invoca esplicitamente il fallimento della transazione 3. Forzature di sistema: la parte del DBMS responsabile dell avanzamento delle transizioni decide di imporre il fallimento alla transazione per sbloccare una situazione critica (STALLO) 4. Crash del sistema e guasti hardware: rottura di un disco o black out elettrico Proprietà ACID transazione: una sequenza di azioni sulla base di dati che gode delle proprietà ACID: 1. Atomicità: la transazione deve produrre tutti gli effetti desiderati o non produrre alcun effetto 2. Consistenza: la transazione fa passare la BD da uno stato consistente ad un altro stato consistente 3. Isolamento: assenza di interferenze tra diverse transazioni che accedono concorrentemente alla BD 4. Durevolezza (o persistenza): gli effetti di una transazione committed rimangono persistenti anche in caso di successive situazioni di errore eccezionali (crash) 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 eseguisse tutte le sue azioni in un solo passo, oppure non ne eseguisse alcuna. Il DBMS registra tutte le azioni così da poter annullare le azioni delle transazioni abortite 2

3 Controllo della concorrenza La proprietà dell isolamento è assicurata se tutte le transazioni vengono eseguite in modo seriale: prima tutte le azioni di una transizione, poi tutte quelle di un altra, e così via Tale vincolo di serialità allunga però i tempi di risposta e non sfrutta adeguatamente tutte le risorse disponibili: non è pertanto proponibile Controllo della concorrenza Due transazioni si dicono concorrenti (o parallele) se una ha inizio prima della terminazione dell altra le frecce indicano vincoli temporali da rispettare per evitare interferenze (a2 non puo iniziare prima del termine di b1 e b3 non puo iniziare prima del termine di a3) Bisogna permettere pertanto che due transazioni possano procedere concorrentemente (in parallelo) Transazioni concorrenti (schema) Schedulazioni T1 T2 T1 T2 T1 T2 a1 a2 a1 a3 a4 a2 a3 a5 a4 b1 b2 b3 a1 a2 a3 b1 b2 b1 b2 b3 b4 a5 b4 a4 a5 b3 b4 tempo L esecuzione concorrente di azioni non comporta necessariamente una riduzione del tempo totale di esecuzione rispetto ad una esecuzione seriale L esecuzione concorrente di transazioni equivale in genere a permettere che le azioni di più transazioni possano intercalarsi nel tempo Le possibili intercalature sono note come schedulazioni Il DBMS possiede una componente chiamata ordinatore o schedulatore che riceve e ordina ( schedula ) le azioni delle diverse transazioni 3

4 Esempio? Consideriamo due transazioni T1: BEGIN A=A+100, B=B-100 END T2: 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 Schedule S E una lista di azioni (R,W,A,C) in un insieme di transazioni dove: l ordine delle azioni nello S deve essere lo stesso di T. Lo S descrive le azioni come sono eseguite dal DBMS Esempio (segue)? Consideriamo una possibile alternanza (schedule) T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B? Questa va bene. Ma che possiamo dire di T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B? Il DBMS vede il secondo schedule come T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B) Scheduling di transazioni Scheduling seriale: schedule che non alterna le azioni di transazioni differenti ovvero le azioni di T diff. non sono inframmezzate 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: uno schedule che è equivalente a qualche esecuzione seriale delle transazioni Nota: se ogni transazione conserva la consistenza, ogni schedule serializzabile conserva la consistenza 4

5 Anomalie con l esecuzione alternata? Lettura di dati non completati (conflitti WR, letture sporche ) T1 trasferisce, T2 incrementa del 10% T1: R(A), W(A), R(B), W(B), C T2: R(A), W(A), R(B),W(B),C? Letture non ripetibili (conflitti RW) T1: R(A), R(A), W(A), C T2: R(A), W(A), C Anomalie (segue) Sovrascrittura di dati non completati (conflitti WW) voglio rendere uguali due salari T1: W(A), W(B), C T2: W(A), W(B), C Esempio di : Scrittura alla cieca Controllo di concorrenza basato sui lock 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 Lo Strict 2PL permette solo schedule serializzabili Anche il (non strict) 2PL permette solo schedule serializzabili, ma coinvolge un processo di abort più complesso Abortire una transazione 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 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 5

6 Il log 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 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 Giornale delle modifiche Durante una transazione, le informazioni relative a tutti gli eventi vengono registrate sul giornale delle modifiche (database log file) <attivata transazione n> <modificato blocco A, con i nuovi valori V, nella transazione n> <committed transazione n> Ogni transazione è identificata da un numero n assegnato durante l attivazione La consistenza della base dati e la riduzione al minimo della perdita di informazioni in caso di un crash del sistema dipendono dalla gestione del database log file Recupero dopo un crash Sommario 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!) 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 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 6