Gestione del Buffer. Gestione delle Transazioni. Il buffer. Il gestore del buffer 2. Il gestore del buffer 1

Transcript

1 Gestione delle Transazioni Parte terza Argomenti: Gestore del Buffer,Ripristino, File di Log, Protocolli per il ripristino, Savepoint, Shadow Pages, Gestione del Buffer Obiettivi: Minimizzare gli accessi al disco mantenendo blocchi di dati in memoria centrale D Testo di riferimento: B.Catania, E. Ferrari, G. Guerrini Sistemi di Gestione Dati, Edizioni Città Studi Capitolo 8 trasferimento di dati fra disco e memoria centrale Gerarchia di granularita Base di dati File 1 File 2 Pag 11 Pag 12 Pag 13 Pag 21 Pag 22 R111 R121 r131 r211 r221 R112 r132 r222 Il buffer E un area della memoria centrale allocata al DBMS e condivisa dalle transazioni. E organizzata in pagine di dimensioni uguali o multiple di quelle del blocco di I/O usato dal SO Accesso 6 volte piu veloce rispetto ad disco Dimensioni rilevanti Il gestore del buffer 1 Fornisce una serie di primitive e gestisce le operazioni di i/o relative alle stesse. Attua politiche simili a quelle adottate dal SO per la gestione della memoria basate sui seguenti criteri: Il gestore del buffer 2 Principio di località dei dati : I dati a cui si accede correntemente hanno una maggior probabilità di essere usati anche in futuro. Legge empirica: L 80% delle transazioni accede solo al 20% dei dati della BD. 1

2 Gestore del buffer vs SO -Simile a SO (Least Recently Used). - Spesso il DBMS è in grado di predirre l uso dei dati. ESEMPIO : A JOIN B Con A e B su files diversi. A JOIN B Una t-upla di A vs tutte le t-uple di B Poi la t-upla di A non serve piu e puo essere scaricata (strategia toss immediate) B deve essere tenuto in memoria fino all esame di tutte le t-uple (strategia Most Recently Used) Directory Cache del DBMS <indir pg disco, posiz nel buffer> Buffer 1 Buffer 2 Buffer 3 Buffer 4 Buffer 5 P1 P2 P3 Buffer 6 Buffer 7 P4 P5 P6 P7 P8 P9 Flushing P10 P11 P12 Primitive del gestore del buffer fix carica una pagina nel buffer - richiede lettura da disco solo se la pag non è in memoria - la pagina caricata è valida cioè allocata ad una transazione - alla transazione viene fornito il puntatore alla pagina use usata dalla transazione per accedere alla pagina caricata precedentemente - conferma della sua allocazione nel buffer -conferma dello stato di validità Dirty bit incluso spesso nella directory Cache del DBMS Bit di pin-unpin Cache del DBMS Buffer 1 Buffer 1 Buffer 2 Buffer 2 Buffer 3 Buffer 3 0 Buffer in prima registrazione Buffer 4 Buffer 5 0 Pagina trasferibile su disco Buffer 4 Buffer 5 Buffer 6 Buffer 6 Buffer 7 Buffer 7 1 Buffer già modificato 1 Pagina NON trasferibile su disco 2

3 Primitive del gestore del buffer unfix segnala che la transazione ha terminato l uso della pagina che non è piu valida force trasferisce in modo sincrono una pagina dal buffer al disco flush trasferisce in modo asincrono le pagine non piu valide indipendentemente dalle transazioni attive Politiche del gestore del buffer Quando il buffer è pieno l esecuzione di una fix è possibile solo se si esegue la force di una pagina CRITERI Priorità di trasferimento alle pagine non valide (NO-STEAL) Sostituzione di pagine valide (STEAL) IN CASO DI STEAL -FORCE Scrittura forzata prima del commit -NO-FORCE Lasciata all iniziativa del gestore del buffer DB Buffer 1 Buffer 2 Buffer 3 Buffer 4 Buffer 5 Buffer 6 Buffer 7 Replace ment Perché usare il buffer Problemi legati alla scrittura IMMEDIATA delle modifiche apportate delle transazioni sulla Base di Dati. Un esempio : trasferisco 10 euro dal conto X al conto Y. T: r(x), x=x-10, w(x), r(y), y=y+10,w(y) T: X 160 Y Politica usuale NO-STEAL / NO-FORCE 40 Vincolo di integrità : x+y= 200 T: 40 Che disgrazia: un crash di sistema!! T: r(x), x=x-10, w(x), r(y), y=y+10,w(y) X 160 Y Vincolo di integrità : x+y= 200 Cosa fare? 1) Non faccio nulla 2) Rieseguo T STATI DELLA BASE DI DATI CORRETTO Ultima versione completa ed aggiornata VALIDO Parte di uno stato corretto (parte delle informazioni sono state perse) CONSISTENTE Stato valido nel quale sono rispettati i vincoli di consistenza 3

4 Controllo affidabilità gli errori LOGICO Il programma che esegue la transazione non puo proseguire a causa di un errore (Input, Divisione per 0, Overflow etc.) Correggere il programma DI SISTEMA L esecuzione della transazione non puo proseguire per problemi di sistema( deadlock, conflitto, etc..) Rilanciare la transazione Controllo affidabilità i guasti Crash di sistema Mancanza prolungata corrente elettrica Crash del disco Problemi fisici o catastrofici (incendi allagamenti, terremoti, meteore, dinosauri.???) AFFIDABILITA E Controllo affidabilità obiettivi Il DBMS deve garantire che - Le operazioni delle transazioni siano completate con successo - Il loro effetto sia memorizzato permanentemente nella BD OPPURE La transazione non abbia alcun effetto sulla BD e sulle altre transazioni Affidabilita transazioni Astrazione della MEMORIA STABILE Il file di LOG Affidabilità della memoria Memoria Volatile (Mem Centrale e Registri) A = 10 3 ore Distrutta da guasto del sistema Memoria NON Volatile (Dischi, CD etc..) A = alcuni anni Distrutta da guasto del supporto di memorizzazione. Memoria Stabile (ASTRAZIONE) A = 7 *10 2 anni Mai Distrutta e realizzata con componenti ridondanti 4

5 Strumenti per il recupero DUMP Scaricamento del contenuto di tutta la memoria su altro supporto LOG (GIORNALE) Registrazione sequenziale su altro supporto di tutte le operazioni svolte sulla memoria a partire dall ultimo DUMP CHECKPOINT (Marca) Segnale periodico memorizzato sul LOG per indicare lo stato delle transazioni in un preciso istante FILE DI LOG File sequenziale che registra in ordine temporale le azioni sugli items compiute dalle transazioni. Ṅ.B. Ogni transazione ha un identificatore generato automaticamente dal sistema FILE DI LOG Un record del file di log puo contenere: Identificatore transazione (t_id) Identificatore del record fisico del DB (r_id) Il valore precedente la modifica del dato (before image (BI)) Il valore del dato modificato (after image (AI)). FILE DI LOG: tipi di record Per le transazioni: begin(t_id) insert (t_id, r_id, AI) delete (t_id, r_id, BI) update (t_id, r_id, BI,AI) insert (t_id, r_id, AI) Commit (t_id) abort (t_id) read (t_id, r_id) non necessario, in genere FILE DI LOG: tipi di record Per il sistema: FILE DI LOG Dump Checkpoint (t_id 1, t_id 2 t_id 3 t_id 4. t_id n.) transazioni transazioni Checkpoints Record di sistema (Dump, rari) 5

6 Scenario DB File di LOG DB Cache del DBMS Buffer 1 Buffer 2 Buffer 3 Buffer 4 Buffer 5 Buffer 6 Buffer 7 Flushing CHECKPOINT Aggiorna il file di log rispetto alle transazioni completate Le pagine del buffer relative alle transazioni committed o abortite vengono TRASFERITE su memoria di massa. Il CP finisce con un operazione di force di un record di Checkpoint (t_id1, t_id2 t_id3 t_id4. t_idn.) contenente gli indicatori delle transazioni ancora attive che proseguono. Checkpoint Operazione periodica : Flush in memoria di transazioni con record di Commit o Abort Checkpoint Viene periodicamente scritto nel log ad ogni flushing Ripristino di checkpoint e transazioni attive Gia trascritte Da trascrivere DUMP Copia periodica di su dispositivo esterno (disco, nastro, cassetta) di - TUTTA la base di dati DANNI FISICI STRATEGIE DI RECOVERY Ripristino vecchia copia della Base di dati Effettuato in background a transazioni ferme Il record di DUMP nel LOG identifica la copia ed il supporto di memorizzazione Indispensabile in caso di GUASTI CATASTROFICI INCONSISTENZA REDO/UNDO delle transazioni 6

7 STRATEGIE DI RECOVERY Ripresa a freddo (Cold Restart ) In caso di arresto del sistema e danni gravi Dump + ripresa a caldo Tecniche per il ripristino Ripresa a caldo (Warm Restart) Guasti ed errori che non richiedono l arresto del sistema Ripristino sulla base del file di log UNDO Primitive per il ripristino UPDATE e DELETE copia nel record r_id la BI INSERT cancella il record r_id REDO UPDATE e INSERT copia nel record r_id la AI DELETE riscrive il record r_id Primitive per il ripristino UNDO le transazioni possono essere disfatte copiando nel record del file oggetto della transazione la BEFORE image REDO le transazioni possono essere rifatte copiando nel record del file oggetto della transazione la AFTER image Write Ahead Log (WAL) I record di log relativi alle operazioni di modifica della BD vengono scritti su memoria stabile PRIMA che i dati vengano effettivamente modificati. Meccanismi di ripristino Variano rispetto a: 1) Sincronizzazione della scrittura sul log 2) Utilizzo primitive undo e redo N.B. Regola base per la correttezza delle operazioni di ripristino 7

8 Protocollo con Modifiche DIFFERITE T (start) partenza <T,start> W(x) record log <T,x> (x è il nuovo valore) T(commit) fine <T,commit> In caso di guasto Vengono rifatte le transazioni che hanno registrato sul log entrambi i record: <T,start> e <T,commit> SOLO a questo punto, i dati modificati vengono trasferiti nella BD N.B. Nessun UNDO Troppo pesante: il buffer non puo scaricare i dati fino al raggiungimento del commit. Ripristino guasto Più transazioni attive e concorrenti Che disgrazia: un crash di sistema!! T: r(x), x=x-10, w(x), r(y), y=y+10,w(y) Ripristino a modifiche differite REDO Nell ordine del LOG di tutte le CT che hanno raggiunto il commit DOPO l ultimo checkpoint (possono essere anche a cavallo) Tutte le transazioni attive e non concluse riavviate. T: 40 X 160 Y Vincolo di integrità : x+y= 200 Qual e il contenuto del file di log?? Cosa accade?? Protocollo con Modifiche NON DIFFERITE T (start) partenza <T,start> W(x) record log <T,x1,x2> (x1 è la BI e x2 la AI) T(commit) fine <T,commit> In caso di guasto Vengono RIFATTE (redo) le transazioni che hanno registrato sul log entrambi i record: <T,start> e <T,commit> Vengono DISFATTE (undo) le transazioni che hanno registrato <T,abort> oppure solo <T,start> In qualunque momento della transazione, i dati modificati vengono trasferiti nella BD, Purchè si siano registrate la BI e la AI di ogni scrittura. 8

9 Protocollo a modifiche differite UNDO -devono essere DISFATTE le transazioni che hanno registrato [ start_transaction, T] ma NON [ commit, T ] REDO Devono essere RIFATTE TUTTE le Committed transactions Recovery guasto Più transazioni attive e concorrenti REDO Nell ordine del LOG di tutte le CT che hanno raggiunto il commit DOPO l ultimo checkpoint (possono essere anche a cavallo) Tutte le transazioni attive e/o non concluse Annullate (UNDO) e riavviate. Che disgrazia: un crash di sistema!! T: r(x), x=x-10, w(x), r(y), y=y+10,w(y) Ripristino a modifiche NON differite Transazioni Flat -Commit/Abort in modo esclusivo -Commit/Abort come ultima istruzione eseguita T: X 160 Y Ordinamento seriale delle operazioni 40 Vincolo di integrità : x+y= 200 Qual e il contenuto del file di log?? Cosa accade?? Limite: Il livello di isolamento Tutto o Niente Transazioni Flat Limite: Il livello di isolamento Tutto o Niente:esempi -Operazioni ripetitive : -accreditamento interessi a tutti i conti bancari) -Operazioni modulari : prenotazione volo aereo con diversi scali alternativi BOT FOR ogni conto c DO UPDATE c END FOR EOT BOT PRENOTA CA-MI PRENOTA MI-PARIGI PRENOTA PARIGI-NY EOT Savepoint E il punto di invocazione della primitiva SAVEWORK per un rollback selettivo. SAVEWORK Registra lo stato corrente della transazione Rende un etichetta utilizzata per tornare al savepoint 9

10 BOT con SAVEPOINT 1 implicito Istruzione 1 Istruzione 2 SAVEWORK 2 savepoint N. 2 Istruzione 3 Istruzione 4 SAVEWORK 3 Solo questa parte viene annullata Istruzione 5 RollbackWork (2) Istruzione 6 Istruzione 7 SAVEWORK 4 savepoint N. 4 Istruzione 8 Commit EOT Transazioni e SQL -Tutti i comandi sono recepiti ABORT,COMMIT,SAVEPOINT etc -Specificazione del livello di isolamento START TRANSACTION [<modo di accesso <livello di isolamento> <dimensione diagnostica>] Tipologia di operazioni (ROnly,RW) Numero max di condizioni di errore gestite Livello di isolamento MINIMO :READ UNCOMMITTED N.B. Per RO e statistiche -READ COMMITTED (RC) su VLDB Esempio gestione ROLLBACK A Cascata con RC R(x)W(y) R(w) T1 R(y)W(y) R(z)W(z) T2 -REPETABLE READ (RR) - MASSIMO :SERIALIZABLE T3 R(z)W(z) T3: annullata perché non raggiunge commit T2: annullata perché ha letto z scritto da T3 e rifatta col vecchio valore di z T1: o.k. guasto Le shadow pages Rappresentano un alternativa al ripristino basato su LOG Durante l esecuzione di T si conservano : -La tabella delle pagine correnti -La tabella delle shadow page -Quando T comincia le due PG sono uguali. -L UPDATE avviene sulle pagine correnti. - Le shadow restano inalterate e servono da BI. -Al commit di T PG correnti PG shadow. Directory PG correnti Directory shadow PG P1 P2 P3 P1 P2 P3 P4 P5 P6 P4 P5 P6 P7 P8 P9 P7 P8 P9 P10 P11 P12 P10 P11 P12 10

11 -PREGI Le shadow pages -Il file di log NON esiste (non devo crearlo, aggiornarlo etc) Flat, savepoint, livello di isolamento -Il recovery è piu veloce (nessun UNDO / REDO) DIFETTI -Frammentazione dei dati -Garbage collection 11