TRANSAZIONI TRANSAZIONI

Transcript

1 TRANSAZIONI Concetto di transazione, comandi di transazione, proprietà ACID delle transazioni Transazioni concorrenti Esecuzione seriale e serializzabile Conflict-equivalenza, grafo dei conflitti Protocollo 2PL e 2PL stretto Protocollo basato su timestamp Lo stallo Gestione dei buffer Affidabilità Malfunzionamenti, do/undo/redo Il LOG Checkpoint Dump Transazioni 1 TRANSAZIONI TRANSAZIONE una singola esecuzione di un programma una unità di lavoro effettuata da un applicazione una unità di lavoro consistente e affidabile Transazioni 2 1

2 Esempio di transazione ESEMPIO: prenotazione di un volo da P1 a P3 con cambio in P2 1. num. posti disponibili volo P1 P num. posti occupati volo P1 P num. posti disponibili volo P2 P num. posti occupati volo P2 P3 ++ vincolo integrità: occupati + disponibili = k malfunzionamento tra 1. e 2. dati inconsistenti rispetto al vincolo di integrità malfunzionamento tra 2. e 3. dati consistenti rispetto al vincolo di integrità dati non corretti Transazioni 3 Esempio di transazione ESEMPIO: prenotazione di un volo da P1 a P3 con cambio in P2 Istruzioni in linguaggio macchina 1 a. leggi num 1 b. somma 1 1 c. scrivi num... esecuzione concorrente da parte di più transazioni di 1a., 1b., 1c. il valore di num può non essere corretto Transazioni 4 2

3 Esecuzione di una transazione database in uno stato consistente database in uno stato consistente il database può essere temporaneamente in uno stato inconsistente inizio transazione fine transazione esecuzione della transazione Transazioni 5 Esempio-1 di transazione [5] FLIGHT (Fno,Date, Src, Dest, Seatsold, Capacity) CUST (Cname, Addr, Bal) FC (Fno, Date, Cname, Special) Begin_transaction Reservation begin input (flight_no, date, customer_name); EXEC SQL UPDATE FLIGHT SET Seatsold = Seatsold + 1 WHERE Fno = flight_no AND Date = date; EXEC SQL INSERT INTO FC (Fno, Date, Cname, Special) VALUES (flight_no, date, customer_name, NULL); output ( reservation completed ) end Affinché l esecuzione sia corretta devono essere eseguiti ambedue i comandi SQL Transazioni 6 3

4 TRANSAZIONI / COMANDI BEGIN TRANSACTION END TRANSACTION COMMIT WORK ROLLBACK WORK i comandi begin transaction e end transaction racchiudono le istruzioni che compongono il corpo della transazione il comando commit work segnala al sistema che gli effetti sul database devono essere resi permanenti deve essere eseguita una operazione di commit il comando rollback work segnala al sistema che gli effetti delle istruzioni eseguite fino a quel momento devono essere annullati deve essere eseguita una operazione di abort Transazioni 7 TRANSAZIONI BEN FORMATE una transazione è ben formata se inizia con begin transaction finisce con end transaction esegue commit work o rollback work (o l uno o l altro) dopo commit work o rollback work non esegue letture e/o scritture sul database si può vedere se una transazione è ben formata solo al momento della sua esecuzione non sempre i comandi visti devono essere scritti esplicitamente dall utente si noti che l operazione abort può essere eseguita dal sistema a seguito dell esecuzione di un rollback work, o può essere decisa dal sistema autonomamente in base alla situazione Transazioni 8 4

5 TRANSAZIONI / COMANDI SQL commit rollback non esistono begin transaction e end transaction una istruzione SQL è implicitamente la prima istruzione di una transazione (transazione corrente) se non esiste già una transazione corrente i comandi commit e rollback segnalano anche la fine della transazione ogni istruzione SQL che segue un commit o un rollback è la prima istruzione di una nuova transazione il comando set transaction serve ad eventualmente definire le caratteristiche della transazione corrente Transazioni 9 Esempio-2 di transazione [5] FLIGHT (Fno,Date, Src, Dest, Seatsold, Capacity) CUST (Cname, Addr, Bal) FC (Fno, Date, Cname, Special) Begin_transaction Reservation begin input (flight_no, date, customer_name); EXEC SQL SELECT Seatsold, Capacity INTO temp1, temp2 FROM FLIGHT WHERE Fno = flight_no AND Date = date; if temp1 = temp2 then begin output ( no free seats ); Rollback end else.. Transazioni 10 5

6 Esempio-2 di transazione [5] FLIGHT (Fno,Date, Src, Dest, Seatsold, Capacity) CUST (Cname, Addr, Bal) FC (Fno, Date, Cname, Special).. begin EXEC SQL UPDATE FLIGHT SET Seatsold = Seatsold + 1 WHERE Fno = flight_no AND Date = date; EXEC SQL INSERT INTO FC (Fno, Date, Cname, Special) VALUES (flight_no, date, customer_name, NULL); Commit; output ( reservation completed ) end end-if end Transazioni 11 TRANSAZIONI / PROPRIETA proprietà acide delle transazioni ACID Atomicity atomicità Consistency consistenza Isolation isolamento Durability persistenza Transazioni 12 6

7 TRANSAZIONI / ATOMICITA la transazione è una unità di elaborazione indivisibile: tutto o niente se la transazione esegue un commit tutte le sue modifiche vengono rese permanenti e visibili alle altre transazioni se la transazione va in abort, è come se non fosse mai iniziata il sistema deve riportare lo stato del database a quello che si aveva prima dell inizio della transazione il sistema deve disfare quello che la transazione ha fatto l abort può essere provocato da esecuzione di un rollback malfunzionamento che causa l interruzione della transazione decisione del sistema ad esempio nel trattamento dello stallo Transazioni 13 TRANSAZIONI / CONSISTENZA una transazione non deve violare i vincoli di integrità definiti sul database i vincoli di integrità possono essere controllati in modo immediato, dopo ogni aggiornamento modo differito, al momento del commit es: inserimenti in tabelle con vincoli di integrità referenziale ciclici Se i vincoli sono controllati in modo immediato, non è possibile fare nessun inserimento Transazioni 14 7

8 TRANSAZIONI / ISOLAMENTO l esecuzione di una transazione è indipendente dall esecuzione concorrente di altre transazioni le modifiche fatte da una transazione sulla base di dati sono visibili alle altre transazioni solo dopo che questa ha effettuato il commit esempio di esecuzione concorrente, non isolata di T 1 e T 2 write 1 (x) read 2 (x) commit 2 abort 1 il dato x letto da T 2 non è valido: T 2 deve essere disfatta e rifatta Transazioni 15 TRANSAZIONI / PERSISTENZA Gli effetti sul database di una transazione andata in commit sono permanenti, non devono andare persi per nessun motivo (es. malfunzionamenti) Transazioni 16 8

9 TRANSAZIONI CONCORRENTI T 1 r 1 (x); e 1 : x=x+100; w 1 (x); commit 1 T 2 r 2 (x); e 2 : x=x-200; w 2 (x); commit 2 x 0 : 1000 esecuzione concorrente r 1 (x) r 2 (x) e 2 e 1 w 2 (x) w 1 (x) c 1 c 2 x f : 1100 risultato non corretto esecuzione seriale di transazioni una esecuzione di T={T 1, T n } è seriale se (T i, T j ) tutte le operazioni di T i vengono eseguite prima di T j o viceversa esecuzione serializzabile di transazioni una esecuzione di T={T 1, T n } è serializzabile se ha sul DB lo stesso effetto di una esecuzione seriale una esecuzione serializzabile è corretta Transazioni 17 ESEMPI ESECUZIONE CONCORRENTE T 1 r 1 (x); e 1 : y=x+1; w 1 (y); c 1 T 2 r 2 (y); e 2 : z=y+1; w 2 (z); c 2 T 3 r 3 (z); e 3 : x=z+1; w 3 (x); c 3 x 0 = y 0 = z 0 = 0 esecuzione seriale T 1 T 2 T 3 r 1 e 1 w 1 c 1 r 2 e 2 w 2 c 2 r 3 e 3 w 3 c 3 x=3 y=1 z=2 esecuzione serializzabile ( T 1 T 3 T 2 ) r 1 r 3 e 3 w 3 c 3 e 1 w 1 c 1 r 2 e 2 w 2 c 2 x=1 y=1 z=2 esecuzione non serializzabile r 2 r 1 r 3 e 2 w 2 c 2 e 1 w 1 c 1 e 3 w 3 c 3 x=1 y=1 z=1 Transazioni 18 9

10 ESEMPI ESECUZIONE CONCORRENTE esecuzione seriale T 1 T 2 r(a) A=A-1 w(a) r(b) B=B+1 w(b) c r(b) B=B-2 w(b) r(c) C=C+2 w(c) c esecuzione serializzabile T 1 r(a) A=A-1 w(a) r(b) B=B+1 w(b) c T 2 r(b) B=B-2 w(b) r(c) C=C+2 w(c) c esecuzione non serializzabile T 1 r(a) A=A-1 w(a) r(b) B=B+1 w(b) c T 2 r(b) B=B-2 w(b) r(c) C=C+2 w(c) c T 1 legge B prima che T 2 l abbia aggiornato Transazioni 19 SCHEDULE (STORIA) DI TRANSAZIONI consideriamo solo le operazioni: lettura, scrittura, commit, abort nessuna transazione legge o scrive un dato più di una volta l esecuzione di T i è un ordinamento su un insieme di operazioni tale che O i {r i (x), w i (x)} { c i, a i } solo una delle due operazioni commit o abort è presente l ultima operazione è commit o abort Dato T= {T 1 T n } una storia (schedule) S su T è un ordinamento su un insieme di operazioni O = i O i che rispetta l ordinamento di ogni T i Transazioni 20 10

11 CONFLICT-EQUIVALENZA DI STORIE due operazioni p e q sono in conflitto se operano sullo stesso dato e almeno una di esse è una scrittura in questo contesto, consideriamo solo transazioni terminate da un commit (commit-proiezione di storie) due storie S 1 e S 2 sono conflict-equivalenti se contengono le stesse operazioni e ordinano allo stesso modo operazioni in conflitto una storia è conflict-serializzabile se è conflict-equivalente ad una storia seriale Transazioni 21 CONFLICT-EQUIVALENZA esempi T 1 r 1 (x) w 1 (x) w 1 (y) c 1 T 2 r 2 (x) w 2 (y) c 2 T 3 r 3 (x) w 3 (x) c 3 S 1 r 2 (x) r 1 (x) w 1 (x) r 3 (x) w 1 (y) c 1 w 2 (y) c 2 w 3 (x) c 3 S 2 r 1 (x) r 2 (x) w 1 (x) r 3 (x) w 3 (x) c 3 w 1 (y) w 2 (y) c 2 c 1 S 3 r 2 (x) r 1 (x) w 1 (x) r 3 (x) w 3 (x) c 3 w 2 (y) w 1 (y) c 2 c 1 S 1 c-equiv S 2 S 1 non è c-equiv S 3 S 3 è c-serializzabile S 3 è c-equiv storia seriale T 2 T 1 T 3 S 1 non è c-serializzabile Transazioni 22 11

12 GRAFO DEI CONFLITTI grafo dei conflitti relativo alla storia S: CG(S) ad ogni transazione corrisponde un nodo si ha un arco T i T j (i j) se e solo se almeno una operazione di T i precede e va in conflitto con una operazione di T j S 2 r 1 (x) r 2 (x) w 1 (x) r 3 (x) w 3 (x) c 3 w 1 (y) w 2 (y) c 2 c 1 T3 T2 T1 S 3 r 2 (x) r 1 (x) w 1 (x) r 3 (x) w 3 (x) c 3 w 2 (y) w 1 (y) c 2 c 1 T3 T2 T1 Transazioni 23 TEOREMA DI SERIALIZZABILITA una storia S è conflict-serializzabile se e solo se il suo grafo dei conflitti è aciclico S 2 non è conflict-serializzabile S 3 è conflict-serializzabile determinare se un grafo è aciclico ha complessità lineare rispetto al numero dei nodi grafi grandi e dinamici Transazioni 24 12

13 CONTROLLO CONCORRENZA: lock vincoli sulle operazioni lettura/scrittura effettuate dalle transazioni: ogni operazione di lettura deve essere preceduta dalla richiesta read_lock e seguita da read_unlock r_lock(x) read(x) r_unlock(x) ogni operazione di scrittura deve essere preceduta dalla richiesta write_lock e seguita da write_unlock w_lock(x) write(x) w_unlock(x) transazioni che seguono questo protocollo sono ben formate rispetto al locking Transazioni 25 CONTROLLO CONCORRENZA: lock gestione dei lock: i lock sono gestiti dal lock manager che tiene traccia dei lock assegnati alle varie transazioni tabella dei lock: [dato_id, tipo_lock, transazione_id] un r_lock(x) viene accordato solo se non è già stato assegnato un w_lock(x) un w_lock(x) viene accordato solo se nessun tipo di lock su x è già stato assegnato (la risorsa x è libera) se una T ottiene un lock continua la sua esecuzione se una T non ottiene un lock, ne viene sospesa l esecuzione in attesa di poterlo ottenere una operazione di unlock annulla l assegnazione del corrispondente lock ad ogni operazione unlock(x) il lock manager controlla se ci sono T in attesa di un lock(x) e se è possibile accordarlo Transazioni 26 13

14 PROTOCOLLO 2PL two phase locking una transazione non può ottenere nessun lock dopo aver effettuato un unlock storia 2PL: esecuzione concorrente di transazioni che seguono il protocollo 2PL num. di lock ottenuti t begin end Transazioni 27 SERIALIZZABILITA DELLE STORIE 2PL il grafo dei conflitti di una storia 2PL è aciclico una storia 2PL è quindi serializzabile Transazioni 28 14

15 PROTOCOLLO A DUE FASI STRETTO strict 2PL consideriamo situazioni reali in cui ci possono essere abort il protocollo 2PL non garantisce l isolamento w_l 1 (x) w 1 (x) w_u 1 (x) r_l 2 (x) r 2 (x) r_u 2 (x) c 2 a 1 protocollo 2PL stretto: una transazione esegue tutti gli unlock solo dopo il commit (abort) num. lock t begin commit end Il protocollo 2PL stretto limita il grado di concorrenza ma dà l isolamento Transazioni 29 CONTR. CONCORRENZA / TIMESTAMP ad ogni transazione viene assegnato un timestamp (marca temporale) i timestamp sono ordinati in modo consistente con l inizio esecuzione delle transazioni valore dell orologio, intero progressivo, obbiettivo scheduler TS: esecuzione di storie serializzabili equivalenti alla storia seriale corrispondente all ordinamento dei timestamp ad ogni dato x vengono associati max_read(x) timestamp più grande delle T che hanno letto x max_write(x) timestamp più grande delle T che hanno scritto x Transazioni 30 15

16 CONTR. CONCORRENZA / TIMESTAMP gestione richieste lettura e scrittura da parte di T con timestamp ts read(x, ts) write(x, ts) read(x, ts): se ts<max_write(x) allora T viene abortita se ts>max_write(x) allora l operazione viene accettata e max_read(x) max(ts, max_read(x)) write(x, ts): se ts<max_write(x) oppure ts<max_read(x) allora T viene abortita altrimenti l operazione viene accettata e max_write(x) ts gestione corretta nell ipotesi di commit proiezione (non si ha isolamento) Transazioni 31 Confronto CS: insieme delle storie conflict-serializzabili 2PL: insieme delle storie ottenibili con il protocollo 2PL TS: insieme delle storie ottenibili con il controllo basato su timestamp CS 2PL TS Transazioni 32 16

17 Confronto S: r 1 (x) w 1 (x) r 2 (x) w 2 (x) r 3 (y) w 1 (y) S è conflict-serializzabile, equivalente alla storia seriale T 3 T 1 T 2 S non è 2PL perché T 1 ha rilasciato x (altrimenti T 2 non avrebbe potuto leggerlo) e poi ha chiesto un lock in scrittura su Y T 1 T 2 T 3 Transazioni 33 Confronto S: r 1 (x) w 2 (x) r 3 (x) r 1 (y) w 2 (y) r 1 (v) w 3 (v) r 4 (v) w 4 (y) w 5 (y) non 2PL S è conflict-serializzabile, equivalente alla storia seriale T 1 T 2 T 3 T 4 T 5 S è compatibile con il protocollo basato su timestamp S non è 2PL perché T 2 ha rilasciato x (altrimenti T 3 non avrebbe potuto leggerlo) e poi ha chiesto un lock in scrittura su Y T 1 T 2 T 5 T 4 T 3 Transazioni 34 17

18 Confronto S: r 1 (x) w 1 (x) r 2 (x) w 2 (x) S è 2PL e anche TS S: r 2 (x) w 2 (x) r 1 (x) w 1 (x) S è 2PL ma chiaramente non è TS Transazioni 35 STALLO Con i protocolli basati su lock possono verificarsi situazioni di stallo Esempio di stallo r_lk 1 (x) r_lk 2 (y) r 1 (x) r_ 2 (y) w_lk 1 (y) w_lk 2 (x) La transazione T 1 chiede un lock in scrittura su y e viene messa in attesa perché y è bloccato da T 2 La transazione T 2 chiede un lock in scrittura su x e viene messa in attesa perché x è bloccato da T 1 Nessuna delle due transazioni può andare avanti La probabilità che si verifichi uno stallo è bassa ma non nulla In caso di stallo il grafo delle attese presenta un ciclo T 1 attende che T 2 rilasci y e T 2 attende che T 1 rilasci x y T 1 T 2 x Transazioni 36 18

19 Tecniche per lo stallo: timeout Viene stabilito un limite per il tempo che una transazione può stare in attesa di un lock, scaduto il timeout viene mandata in abort Importanza della scelta di un intervallo adeguato Troppo corto: abort non necessario perché in realtà invece di uno stallo si aveva un attesa lunga Troppo lungo: permanenza del sistema in stallo prima di prendere provvedimenti Tecnica semplice Tecnica spesso usata dai DBMS commerciali Transazioni 37 Tecniche per lo stallo: prevenzione Con questo tipo di tecniche si seguono dei protocolli che fanno sì che non possa verificarsi uno stallo Cfr. sistemi operativi: tecniche che impediscono una delle quattro condizioni necessarie per lo stallo Acquisendo all inizio tutte le risorse necessarie, si nega la condizione possesso e attesa Con il protocollo che vedremo basato sui timestamp, si impediscono cicli nel grafo delle attese Tecnica A: richiedere inizialmente tutti i lock necessari Non è facile da utilizzare perché non sempre le transazioni conoscono a priori tutti i dati che hanno bisogno di bloccare Transazioni 38 19

20 Tecniche per lo stallo: prevenzione basata su timestamp Ad ogni T viene assegnato un timestamp, sia i il timestamp assegnato a T i : T i aspetta per un dato posseduto da T j se e solo se i <j, cioè se e solo se T i è più vecchia di T j altrimenti T i viene mandata in abort e fatta ripartire con lo stesso timestamp Delle due transazioni, viene eventualmente mandata in abort la più giovane (si suppone che abbia fatto meno lavoro da disfare) È una tecnica senza preemption (T j mantiene il dato che ha bloccato) Ci sono protocolli simili che invece effettuano una preemption Ripartire con lo stesso timestamp invecchia la transazione, e impedisce che in caso di conflitto sia sempre quella ad andare in abort Si può facilmente dimostrare che con questa tecnica il grafo delle attese non ha mai cicli (si dimostra per assurdo) Tecnica non usata nei DBMS commerciali: troppi abort Transazioni 39 Tecniche per lo stallo: rilevamento Ricerca di un ciclo nel grafo delle attese / Analisi delle tabelle di lock Es: Lock assegnati a T Transazioni in attesa di lock lock Trans Trans lock r_l(x) T i T k r_l(y) w_l(y) T i T i w_l(u) w_l(z) T j r_l(u) T k Esaminando le due tabelle si può verificare se siamo in stallo o no Quando effettuare il controllo Periodicamente Quando scade un timeout Tecnica usata da alcuni DBMS commerciali Transazioni 40 20

21 GESTIONE DEI BUFFER BUFFER: area in memoria centrale spartita tra le transazioni area buffer organizzata in pagine dim. pagina dim. blocco I/O disco utilizzato dal sistop lettura del dato x da parte della transazione T: determinazione file e blocco-disco B dove x è memorizzato controllo se B è in una pagina P di BUFFER SI: T legge da P NO: il sistema legge B in una pagina P di BUFFER; T legge da P scrittura del dato y da parte della transazione T: determinazione file e blocco-disco B dove y è memorizzato controllo se B è in una pagina P di BUFFER SI: T scrive su P NO: il sistema legge B in una pagina P di BUFFER; T scrive su P scrittura di P su disco (questa scrittura può essere differita) numero di pagine è limitato: politica di sostituzione Transazioni 41 Buffer read(x) x: write(y) y: buff_1 buff_1 x x y y buff_k buff_k Transazioni 42 21

22 STRUTTURE DEL BUFFER MANAGER tabella allocazione pagine: < pagina-buffer, file, blocco-disco, valida, libera> (file, blocco-disco) pagina database Pagina-buffer valida/non valida valida: pagina in uso ad una transazione non valida: pagina non in uso ad alcuna transazione In genere con una richiesta di lettura si ha una pagina in uso ad una transazione, quindi valida; quando la transazione non la usa più, la rilascia e diventa non valida Pagina-buffer libera/non libera libera: pagina che può essere usata per leggere un nuovo blocco non libera: pagina che deve essere copiata su disco prima di usarla per leggere un nuovo blocco Transazioni 43 PRIMITIVE DEL BUFFER MANAGER Operazione fetch ( o fix, use) Viene usata per leggere una pagina in un buffer operazione force su pagina P del buffer richiesta da T: la pagina P viene copiata su disco e T viene sospesa fino al termine della scrittura operazione flush (su pag P del buffer) del buffer manager: la pagina P non più valida, quindi non più usata da una transazione, (e ancora non libera) viene copiata su disco Questa scrittura è asincrona rispetto all esecuzione delle transazioni Transazioni 44 22

23 POLITICHE GESTIONE PAGINE BUFFER steal / no-steal steal: nella sostituzione delle pagine, la vittima può essere anche una pagina valida prima di essere sostituita deve essere copiata su disco se la transazione, che aveva in uso la pagina, successivamente va in abort, deve essere ripristinato il valore iniziale della pagina del database no-steal: nella sostituzione delle pagine la vittima non può essere una pagina valida force / no-force force: tutte le pagine attive di una transazione T vengono copiate su disco quando T effettua il commit no-force: la scrittura delle pagine su disco viene gestita dal buffer manager in modo asincrono rispetto alla transazione (la scrittura può essere effettuata dopo il commit) DBMS: no-steal/ no-force coppia molto frequente Transazioni 45 MALFUNZIONAMENTI E AFFIDABILITA fallimento di transazione: nessuna perdita di dati né in memoria centrale né su disco interruzione da parte dell utente errore di esecuzione violazione vincoli integrità tentativo accedere a dati protetti situazioni di stallo fallimento di sistema (guasto di sistema): perdita del contenuto della memoria centrale anomalia hard/sw con interruzione di tutte le transazioni attive caduta di tensione disastro / crash (guasto di dispositivo): malfunzionamento che danneggia il disco Transazioni 46 23

24 Local Recovery Manager e Buffer Manager Main memory Local Recovery Manager Database stabile read write fetch flush Database Buffer Manager read write Database Buffers o Database volatile Transazioni 47 AFFIDABILITA il controllo dell affidabilità garantisce le proprietà di atomicità e persistenza delle transazioni atomicità: se la transazione va in abort o si ha un guasto di sistema prima del commit, la transazione viene disfatta (undo) persistenza: se una transazione ha effettuato il commit ma non si è sicuri dei suoi risultati sul database, la transazione viene rifatta (redo) memoria stabile: resistente ai guasti (non subisce crash) unità a nastro disco + unità a nastro due dischi a specchio protezione da malfunzionamenti: ridondanza dei dati log (giornale): file su cui vengono registrate le azioni eseguite dalle transazioni checkpoint dump Transazioni 48 24

25 DO / UNDO / REDO <scrittura pag. modificata>; commit fallimento di transazione DB modificato vecchi valori UNDO DB senza modifiche commit; <scrittura pag. modificata> fallimento di sistema DB senza modifiche nuovi valori REDO DB modificato Transazioni 49 STRUTTURA DEL LOG file sequenziale su memoria stabile in cui vengono registrate le azioni effettuate sul database nell ordine temporale di esecuzione azioni eseguite dal sistema dump checkpoint azioni eseguite dalle transazioni Begin (T) Commit (T) Abort (T) Update (T, Object, Before State, After State) Insert (T, Object, After State) Delete (T, Object, Before State) CK... B(T 1 ) I(T 1,O x, AS) C(T 2 ) U(T 1, O y, BS, AS) C(T 1 ) Transazioni 50 25

26 USO DEL LOG undo e redo utilizzano BS e AS (Before State e After State) idempotenza: undo(azione)=undo(undo(azione)) redo(azione)=redo(redo(azione)) i record di log vengono scritti sequenzialmente su un buffer che generalmente viene copiato sul file log quando è pieno Transazioni 51 Logging Main memory LOG stabile read write Local Recovery Manager LOG buffers Database stabile read write fetch flush Database Buffer Manager read write read write Database Buffers o Database volatile Transazioni 52 26

27 CHECKPOINT / DUMP checkpoint: operazione fatta periodicamente dal sistema per limitare la parte di giornale da scandire in caso di malfunzionamenti rifiuta una nuova operazione di commit scrive su disco le pagine P del buffer modificate, relative a transazioni che hanno effettuato un commit scrive nel log un record checkpoint(t 1, T n ) che indica le transazioni attive in quel momento dopo un checkpoint le modifiche sul database effettuate in precedenza da transazioni terminate sono sicuramente su disco dump: copia completa del database rifiuta l attivazione di nuove transazioni attende il completamento delle transazioni attive scrive su disco le pagine P del buffer modificate fa una copia del database (backup) scrive nel log un record dump Transazioni 53 GESTIONE SCRITTURA SUL LOG regola WAL, Write Ahead LOG: il Before State di un record di log deve essere scritto sul file log (in memoria stabile) prima che la modifica sull oggetto venga scritta sul database su disco si è sicuri che quando il nuovo valore viene scritto su disco il vecchio valore sia stato salvato nel log, così si può eventualmente recuperarlo regola CP, Commit-Precedenza: l After State di un record di log deve essere scritto sul file log (in memoria stabile) prima del commit se una transazione effettua il commit, ma le sue pagine modificate non sono state ancora riportate su disco dal buffer manager, e si verifica un malfunzionamento di sistema, la transazione deve essere rifatta con la regola Commit- Precedenza si è sicuri di ritrovare i dati modificati (After State) nel log Transazioni 54 27

28 GESTIONE SCRITTURA LOG E DATABASE schema no-redo la scrittura del record log precede la scrittura sulla base di dati tutte le pagine modificate vengono copiate su disco prima della scrittura del record commit sul log schema no-undo la scrittura del record log precede la scrittura sulla base di dati tutte le pagine modificate vengono copiate su disco dopo la scrittura del record commit sul log schema undo/redo (DB2, ORACLE) le scritture sul database su disco possono avvenire in un momento qualunque rispetto alla scrittura del commit sul log i tre schemi rispettano le regole WAL e CP, scrivono il commit su disco in modo sincrono, si differenziano per il momento in cui scrivono sul database su disco Transazioni 55 GESTIONE GUASTI MODELLO FAIL-STOP (guasto: evento istantaneo) guasto di sistema arresto di tutte le transazioni ripresa a caldo (warm restart) del sistema guasto di dispositivo arresto di tutte le transazioni ripresa a freddo (cold restart) del sistema Transazioni 56 28

29 WARM RESTART CKP guasto t T1 T2 T3 T4 T5 UNDO: T3 T5 completamente REDO: T2 T4 Si ricordi che il checkpoint copia su disco le scritture effettuate dalle transazioni andate in commit Transazioni 57 WARM RESTART 1. si accede al log e lo si percorre all indietro fino all ultimo ckp 2. si costruiscono gli insiemi UNDO_set e REDO_set 3. si disfano le transazioni di UNDO_set ripercorrendo all indietro il log fino al loro inizio (anche prima di ckp) 4. si rifanno le transazioni in REDO_set rifacendo le loro azioni nell ordine in cui compaiono nel log 2.1 UNDO_set:= transazioni elencate nel ckp record 2.2 REDO_set:= 2.3 si scandisce il log: se Begin(T) allora UNDO_set:= UNDO_set T se Commit(T) allora UNDO_set:= UNDO_set - T REDO_set:= REDO_set T Transazioni 58 29

30 COLD RESTART si ricopia il database (la parte deteriorata) dal dump più recente si accede all ultimo record dump sul log si scandisce il log rifacendo tutte le azioni effettuate sul database dalle transazioni andate in commit si effettua una ripartenza a caldo Transazioni 59 30