GESTIONE DELLE TRANSAZIONI

Transcript

1 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

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

3 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 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 a quello delle due transazioni eseguite serialmente in qualche ordine Giorgio Giacinto 2010 Database 6

4 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) Giorgio Giacinto 2010 Database 7 Scheduling di transazioni! Scheduling seriale! schedule che non alterna le azioni di transazioni differenti! 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 coerenza, ogni schedule serializzabile conserva la coerenza Giorgio Giacinto 2010 Database 8

5 Possibili anomalie dell esecuzione concorrente! Conflitti WR - letture sporche! Lettura di dati non completati T1: R(A), W(A), R(B), W(B), Abort T2: R(A), W(A), Commit! Conflitti RW! Letture non ripetibili T1: R(A), W(A), Commit T2: R(A), W(A), Commit Giorgio Giacinto 2010 Database 9 Possibili anomalie dell esecuzione concorrente! Conflitti WW! Sovrascrittura di dati non completati T1: W(A), W(B), C T2: W(A), W(B), C Giorgio Giacinto 2010 Database 10

6 Protocollo Strict 2PL Controllo di concorrenza mediante lock! Ciascuna transazione deve ottenere! un lock C (condiviso) su un oggetto prima di leggere! 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 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 T i viene abortita, tutte le sue azioni devono essere annullate.! Inoltre, se T j legge un oggetto che è stato recentemente scritto da T i, anche T j 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 T i scrive un oggetto, T j può leggerlo solo dopo che T i 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

7 Il log! Il log registra le seguenti azioni! Quando T i scrive un oggetto si registra il vecchio e il nuovo valore! Quando T i 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