1 Tecnologia di un Database Server S. Costantini Dispensa per il Corso di Basi di dati e Sistemi Informativi Il materiale per queste slide e’ stato tratto.

Presentazione sul tema: "1 Tecnologia di un Database Server S. Costantini Dispensa per il Corso di Basi di dati e Sistemi Informativi Il materiale per queste slide e’ stato tratto."— Transcript della presentazione:

1 1 Tecnologia di un Database Server S. Costantini Dispensa per il Corso di Basi di dati e Sistemi Informativi Il materiale per queste slide e’ stato tratto da (material taken from): Phil Bernstein, Lecture notes for a graduate course on Transaction Processing at University of Washington, URL http://research.microsoft.com/~philbe/

2 2 Premessa Questa dispensa integra i contenuti della seconda parte del Capitolo 9 del Libro di Testo del Corso –Atzeni, Ceri, et al., Basi di Dati: concetti, linguaggi e architetture, McGraw-Hill editore. Questa dispensa non sostituisce questo capitolo, che va comunque studiato.

3 3 Implementazione del Locking S. Costantini

4 4 Modello di un Sistema Transazione 1Transazione N Database Server Bot, SQL Queries Commit, Abort Ottimizzatore Query Esecutore Query Scheduler Buffer Manager Recovery manager Database

5 5 Locking Obiettivo: assicurare schedule serializzabili delle transazioni (vedere par. 9.1 e 9.2 del Libro di testo) Implementazione: ritardare le operazioni che possono alterare la serializzabilita’ ponendo blocchi (locks) sui dati condivisi

6 6 Assunzione: operazioni atomiche La Teoria del Controllo di Concorrenza considera le operazioni di Read e Write. Quindi assume assume che esse siano atomiche –altrimenti, dovrebbe considerare le operazioni di piu’ basso livello che implementano Read e Write Read(x) - restituisce il valore corrente di x nel DB Write(x, val) sovrascrive x (l’intera pagina che lo contiene!) Questa assunzione permette di astrarre l’esecuzione delle transazioni a sequenze di Read e Write

7 7 Locking Ciascuna transazione pone un lock su ogni dato al quale intende accedere –il lock e’ una prenotazione –ci sono read locks e write locks –se una transazione ha un write lock su x, allora nessun’altra transazione puo’ avere alcun lock su x Esempio –rl i [x], ru i [x], wl i [x], wu i [x] sono operazioni lock/unlock wl 1 [x] w 1 [x] rl 2 [x] r 2 [x] e’ impossibile –wl 1 [x] w 1 [x] wu 1 [x] rl 2 [x] r 2 [x] e’ OK

8 8 Il Locking di base non basta Non garantisce la serializzabilita’ –rl 1 [x] r 1 [x] ru 1 [x] wl 1 [y] w 1 [y] wu 1 [y] c 1 rl 2 [y] r 2 [y] wl 2 [x] w 2 [x] ru 2 [y] wu 2 [x] c 2 Eliminando i lock operations, abbiamo r 1 [x] r 2 [y] w 2 [x] c 2 w 1 [y] c 1 che non e’ serializzabile Possibile soluzione: ogni transazione acquisisce tutti i lock all’inizio Problema: si limita troppo la concorrenza

9 9 Two-Phase Locking (2PL) Una transazione e’ two-phase locked (2PL) se: –prima di leggere x, pone un read lock on x –prima di scrivere x, pone un write lock on x –mantiene ciascun lock fino a dopo l’esecuzione dell’operazione sul dato –dopo il primo unlock, non puo’ porre nuovi lock Una transazione acquisisce i lock durante la fase crescente e li rilascia nella fase calante Esempio - a pagina precedente, T 2 e’ 2PL, ma non T 1 perche’ ru 1 [x] precede wl 1 [y]

10 10 Recoverability Se T k legge da T i e T i fa abort, T k deve fare abort –Esempio - w 1 [x] r 2 [x] a 1 vuol dire che T 2 deve fare abort Ma se T k ha gia’ fatto commit? –Esempio - w 1 [x] r 2 [x] c 2 a 1 –T 2 non puo’ fare abort dopo il commit L’esecuzione deve essere recoverable: Il commit di una transazione T deve essere successivo al commit delle transazioni da cui legge. –Recoverable - w 1 [x] r 2 [x] c 1 c 2 –Non recoverable - w 1 [x] r 2 [x] c 2 a 1 Si devono sincronizzare le operazioni

11 11 Evitare Abort a cascata (cascading aborts) Per evitare aborti a cascata, lo scheduler deve assicurare che le transazioni leggano solo da transazioni che hanno fatto commit Esempio –evita cascading aborts: w 1 [x] c 1 r 2 [x] –permette cascading aborts: w 1 [x] r 2 [x] a 1 Un sistema che evita cascading aborts garantisce la recoverability.

12 12 Gestione dell’abort Occorre annullare (undo) ogni write, w[x], ripristinando la before image (=il valore di x prima dell’esecuzione di w[x]) Esempio - w 1 [x,1] scrive il valore “1” in x. –w 1 [x,1] w 1 [y,3] c 1 w 2 [y,1] r 2 [x] a 2 –abort T 2 : si ripristina la before image of w 2 [y,1], = 3 Questo non e’ sempre possibile. –Ad esempio, consideriamo w 1 [x,2] w 2 [x,3] a 1 a 2 –a 1 & a 2 non e’ implementabile mediante before images –si noti che w 1 [x,2] w 2 [x,3] a 2 a 1 sarebbe stato OK

13 13 Strictness Un sistema stretto consente di eseguire r i [x] o w i [x] solo se tutte le transazioni precedenti che hanno scritto x hanno gia’ fatto commit o abort. Esempi –stretto: w 1 [x] c 1 w 2 [x] a 2 –non stretto: w 1 [x] w 2 [x] … a 1 a 2 –stretto: w 1 [x] w 1 [y] c 1 w 2 [y] r 2 [x] a 2 –non stretto: w 1 [x] w 1 [y] … w 2 [y] a 1 r 2 [x] a 2 “Stricness” implica “evitare cascading aborts.”

14 14 2PL e Recoverability 2PL non garantisce la recoverability La seguente esecuzione e’ non-recoverable, ma e’ 2PL wl 1 [x] w 1 [x] wu 1 [x] rl 2 [x] r 2 [x] c 2 … c 1 –dunque, 2PL non e’ stretta e consente cascading aborts Per garantire la strictness bisogna che i write locks vengano rilasciato dopo commit o abort

15 15 Brain Concurrency Control Se l’utente legge su display un output della transazione T i, e vuole usarlo come input per la transazione T k, deve aspettare che T i faccia commit prima di lanciare T k. Solo cosi’ e’ garantito che T i venga effettivamente serializzata prima di T k.

16 16 Locking Automatizzato 2PL puo’ essere reso trasparente per l’ applicazione quando un data manager riceve una Read o Write da una transazione, emette un lock di read o write. Come fa il data manager a sapere quando e’ ok rilasciare i locks (per essere two-phase)? Di solito, il data manager mantiene i lock di ogni transazione finche’ essa fa commit o abort. In particolare: –rilascia i read locks appene riceve il commit –rilascia i write locks solo quando accetta il commit, per garantire la strictness

17 17 Implementazione del 2PL Il data manager implementa il locking cosi’: –includendo un lock manager –generando un lock per ogni Read o Write –prevedendo la gestione dei deadlocks

18 18 Lock manager Il lock manager gestisce le operazioni –Lock(trans-id, data-item-id, mode=r/w) –Unlock(trans-id, data-item-id) –Unlock(trans-id) Memorizza i lock nella lock table. Data ItemLista Locks Lista d’attesa x [T 1,r] [T 2,r] [T 3,w] y [T 4,w] [T 5,w] [T 6, r]

19 19 Lock manager (cont.) Il chiamante genera il data-item-id, applicando una funzione di hashing sul nome del dato Infatti, la lock table e’ hashed sul data-item-id Lock e Unlock devono essere atomici, quindi l’accesso alla lock table deve essere “locked” Lock e Unlock vengono chiamati frequentemente. Devono essere molto veloci: < 100 istruzioni. –Non e’ facile, per via delle operazioni compare-e-swap per l’accesso atomico alla lock table

20 20 Lock manager (cont.) In SQL Server 7.0 –I locks nella tabella occupano circa 32 bytes –Ogni lock contiene il Database-ID, Object-Id, e altre informazioni specifiche quali il record id (RID) o la chiave della tupla.

21 21 Deadlock Un insieme di transazioni e’ in deadlock se ogni transazione e’ bloccata, e lo rimarra’ tutti’infinito se il sistema non interviene. –Esempiorl 1 [x]concesso rl 2 [y]concesso wl 2 [x]bloccata wl 1 [y]bloccata e deadlocked

22 22 Deadlock Con il deadlock, 2PL evita le esecuzioni non serializzabili: –Ad es. rl 1 [x] r 1 [x] rl 2 [y] r 2 [y] … w 2 [x] w 1 [y] –oppure (caso della perdita di update) rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] … w 2 [x] w 1 [x] –Per eliminare il deadlock: abort di una transazione –rilascio del lock senza abortire: si viola il 2PL

23 23 Prevenzione del Deadlock Mai concedere un lock che puo’ portare al deadlock Tecnica spesso usata nei sistemi operativi Inutilizzabile nel 2PL, perche’ richiederebbe l’esecuzione seriale delle transazioni. –Esempio per prevenire il deadlock, rl 1 [x] rl 2 [y] wl 2 [x] wl 1 [y], il sistema nega rl 2 [y]

24 24 Prevenzione del Deadlock Prevenire i deadlock non e’ praticabile in generale, perche’ pone eccessivi constraints alle applicazioni. Porre tutti i lock in scrittura tutti’inizio delle transazioni –Previene il deadlock perche’ la transazione “parte” solo se ha tutti i dati a sua esclusiva disposizione –riduce troppo la concorrenza.

25 25 Rilevazione del Deadlock Si cerca di rilevare i deadlock automaticamente, e si abortisce una delle transazioni (la vittima). E’ l’approccio piu’ usato, perche’ –consente una piu’ intensiva utilizzazione delle risorse

26 26 Rilevazione del Deadlock timeout-based deadlock detection - Se una transazione resta bloccata per troppo tempo, allora abortiscila. –Semplice ed efficiente da implementare –Ma determina aborti non necessari e –Alcuni deadlocks persistono troppo a lungo

27 27 Rilevazione Tramite Waits-for Graph Rilevazione esplicita dei deadlock tramite un grafo chiamato Waits-for Graph –Nodi = {transazioni} –Archi = {Ti  Tk | Ti attende che Tk rilasci un lock} –Esempio precedente: T1 T2 Teorema: Se c’e un deadlock, allora il Waits-for Graph ha un ciclo.

28 28 Rilevazione tramite Waits-for Graph (cont.) Per rilevare i deadlocks –quando una transazione si blocca, aggiungi un arco –periodicamente cerca i cicli nel Waits-for Graph Non occorre verificare troppo spesso. (Un ciclo non scompare finche’ non lo si “rompe”) quando si trova un deadlock, si seleziona una vittima dal ciclo e la si abortisce. Si seleziona una vittima che ha fatto poco lavoro (ad es., ha acquisito il numero minimo di lock).

29 29 Ripartenza Ciclica Le transazioni possono ripartire e abortire tutti’infinito. –T 1 inizia. Poi T 2 inizia. –vanno in deadlock, e T 1 (la piu’ vecchia) e’ abortita. –T 1 riparte, T 2 continua, e vanno ancora in deadlock –T 2 (la piu’ vecchia) e’ abortita... Scegliere come vittima la transazione piu’ giovane evita la ripartenza ciclica, perche’ la piu’ vecchia non viene mai abortita, e puo’ infine terminare. Le due diverse euristiche si possono combinare

30 30 SQL Server 7.0 Abortisce la transazione piu’ “economica” per il roll back. –La “piu’ economica” viene determinata in termini del numero di operazioni fatte (registrate nel file di log). –Permette il completamento delle transazioni che hunno fatto molto lavoro. SET DEADLOCK_PRIORITY LOW (vs. NORMAL) permette ad un processo di designarsi da solo come vittima.

31 31 Locking distribuito Supponiamo che una transazione possa accedere dati presso molti data managers Ogni data manager tratta i lock nel modo usuale Ogni transazione esegue commit o abort, nei confronti di tutti i data managers Problema: deadlock distribuito

32 32 Deadlock distribuito Il deadlock interessa due nodi. Il nodo singolo non puo’ rilevarlo La rilevazione tramite timeout e’ la piu’ usata rl 1 [x] wl 2 [x] (bloccata) Nodo 1 rl 2 [y] wl 1 [y] (bloccata) Nodo 2

33 33 Granularita’ dei Lock Granularita’ - dimensione dei dati su cui fare lock –ad es., files, pagine, record, campi Granularita’ grossolana implica: –pochi lock, basso locking overhead –lock su grosse porzioni di dati, alta probabilita’ di conflitti, quindi concorrenza effettiva bassa Granularita’ sottile implica: –molti lock, alto locking overhead –conflitti solo quando due transazioni tentano di accedere concorrentemente proprio lo stesso dato

34 34 Multigranularity Locking (MGL) Lock di differente granularita’ –grosse query fanno lock su grosse porzioni di dati (ad es. tabelle), transazioni brevi fanno lock su pochi dati (ad es. righe) Il Lock manager non puo’ rilevare i conflitti! –ogni data item (ad es. tabella o riga) ha un differente id

35 35 Multigranularity Locking (MGL) Multigranularity locking e’ un “trucco” –sfrutta la naturale struttura gerarchica dei dati –prima del lock su dati di basso livello, si fa un intention lock sulla struttura di piu’ alto livello che li contiene –ad es., prima di un read-lock su una, si fa un intention-read-lock sulla tabella che contiene la riga

36 36 MGL Grafi di Schema e istanza Database area File Record DB1 A1A2 F1 F2 F3 R1.1R1.2R2.1R2.2R2.3R2.1 R2.2 Lock di Schema Lock di istanza Prima di un read lock su R2.3, si fa un intention-read lock su DB1, e poi A2, e poi F2 (i lock si rilasciano all’inverso)

37 37 MGL Matrice di Compatibilita’ r w ir iw riw r y n y n n w n n n n n ir y n y y y iw n n y y n riw n n y n n riw = read con intenzione di write, per scansione che aggiorna alcuni dei record che legge Ad es., ir e’ in conflitto con w, perche’ ir segnala un r-lock su un dato piu’ interno, che e’ in conflitto con un w-lock sulla struttura che lo contiene.

38 38 SQL Server 7.0 SQL Server 7.0 accetta lock su tabelle, pagine, e righe. Usa lock di intention read (“share”) e intention write (“exclusive”) a livello di pagina di tabella.

39 39 Modello Matematico del Locking –N transazioni, ciascuna ottiene K/2 lock in media –KN/2 lock concessi in totale –Ciascuna richiesta ha probabilita' KN/2D di conflitto con un lock esistente. –Ciascuna transazione richiede K locks, quindi la sua probabilita' di entrare in conflitto e' K 2 N/2D. –La probabilita' di deadlock e' proporzionale a K 4 N/D 2 –Prob(deadlock) / Prob(conflitto) = K 2 /D –Se K=10 e D = 10 6, allora K 2 /D =.0001 K lock per transazione D lockable data items N transazioni T tempo tra richieste di lock

40 40 Hot Spot Techniques Hot spot - un data item che e’ piu' usato di altri, per cui molte transazioni ne fanno uso. –cataloghi ed elenchi –end-di-file marker –contatori usati per assegnare numeri seriali Gli hot spots spesso creano un collo di bottiglia che serializza le transazioni.

41 41 Hot Spot Techniques (cont.) Sono necessarie tecniche per ridurre il tempo t di durata di un lock sugli hot data –mantenere gli hot data in memoria centrale –rimandare al commit le operationi su hot data –usare strategie “ottimistiche” –eseguire in batch le operazioni su hot data –partitionare gli hot data

42 42 Rimandare le Operazioni al Commit Il data manager registra le operazioni di ciascuna transazione sugli hot data item. Richiede i lock ed effettua gli updates dopo il Commit della transazione Molti sistemi usano questa tecnica per –Data Entry nel DB –DB residenti in memoria centrale Funziona per write, inserire, delete, ma non per read

43 43 Controllo di concorrenza “ottimistico” Idea - eseguire le operazioni sui copie dei dati senza richiedere i lock. Al commit, testare se vi sono conflitti sui lock. spesso usata nei sistemi client/server –il client fa tutti gli updates nella cache senza lock –al commit, tenta di ottenere i lock ed effettua gli update

44 44 Batching Ogni transazione crea un mini-batch con gli update, e solo periodicamente applica il mini-batch agli hot data condivisi. –ciascun processo ha un data entry file privato, in aggiunta ad un data entry file globale –ciascuna transazione aggiunge gli update al proprio file –periodicamente appende il proprio file al file condiviso

45 45 Partizionamento Suddividere cataloghi e inventari in parti Ciascuna transazione puo’ accedere solo una partizione. Esempio –ciascuna biglietteria ha una parte dei biglietti –se li vende tutti, deve richiedere altri biglietti dalle altre biglietterie

46 46 Tecniche di Query-Update Le query durano molto tempo e fanno lock su molti dati — degradano la performance se competono con brevi transazioni di update Esistono diverse soluzioni –Usare un data warehouse –Accettare vincoli di consistenza piu’ deboli –Usare multiversioni dei dati

47 47 Data Warehouse Un data warehouse e’ una copia del DB, che e' periodicamente aggiornata Tutte le query girano sul data warehouse Tutte le transazioni di update girano su DB Separazione fra transazioni e query Quanto spesso aggiornare il data warehouse? –Stop alle transazioni per copiare il DB nel data warehouse. E’ possibile invece effettuare query –Le query non hanno sempre l’ultima versione dei dati

48 48 Multiversioni dei Dati La granularita’ del locking deve arrivare al record ciascuna write crea una nuova versione, invece di sovrascrivere il valore esistente. Ciascun record ha una sequenza di versioni. Ogni versione e’ annotata con l’id della transazione che ha scritto quella versione Tid TidPrec.MatrNome Stipendio 123 null1Bill100 175 1231Bill125 134 null2Sue120 199 1342Sue140 227 null27Steve80

49 49 Multiversioni dei Dati (cont.) Si eseguono le transazioni usando 2PL Si eseguono le query in snapshot mode –il sistema mantiene la lista delle transazioni che hanno fatto commit con successo (transazioni committed), detta commit lista. –ogni query all’inizio della sua esecuzione copia la commit lista –quando una query legge x, legge l’ultima versione di x scritta da una transazione che e’ nella sua commit lista. –cosi', ogni query fa riferimento allo stato del database relativo a quando ha iniziato l'esecuzione

50 50 Gestione della Commit lista Il data manager mantiene e periodicamente aggiorna un tid T-Oldest, tale che –il tid di ogni transazione attiva e' maggiore di T-Oldest –ogni nuovo tid e' maggiore di T-Oldest –per ogni transazione committed con tid  T-Oldest, le sue versioni sono committed –per ogni transazione abortita con tid  T-Oldest, le versioni sono state eliminate Le query mantengono la parte della commit lista con tid > T-Oldest

51 51 Fantasmi Problemi nell’uso di 2PL con inserire e delete T 1 : Read Conti 1, 2, e 3 T 2 : inserire Conti[4, Ancona, 100] T 2 : Read Sedi(Ancona), restituisce 500 T 2 : Write Sedi(Ancona, 600) T 1 : Read Sedi(Ancona), restituisce 600 T 1 : Commit N# Sede TotaleLuogo Totale 1 Pescara 400 2 Ancona 200 3 Ancona 300 Pescara 400 Ancona 500 Conti Sedi il record fantasma

52 52 Il problema del fantasma T 1 dovrebbe fare lock sul record 4, che non c’e’! Quale delle operazioni di T 1 determina che ci sono solo 3 record? –Read end-di-file? –Read del numero dei record? –SQL Select? L’operazione in conflitto con T 2 e’ esattamente inserire Conti[4,Ancona,100] Quindi, inserire conti[4,Ancona,100] dovrebbe essere eseguita dopo il commit di T 1

53 53 Evitare i fantasmi - Predicate Locks Supponiamo che una query legga tutti i records che soddisfano un predicato P. Ad esempio, –Select * From Conti dove Sede = “Ancona” –Normalmente, una funzione hash trasforma la chiave di ogni record in un record id intero –questo id si usa per il lock

54 54 Evitare i fantasmi - Predicate Locks Sarebbe meglio porre un read lock sul P –che dovrebbe entrare in conflitto con un write lock su Q se qualche record soddisfa (P e Q) –Ad es. T 1 pone un read lock su tutti i record con Sede = “Ancona” –Conflitto con write lock di T 2 che appunto vuole scrivere un record con Sede = Ancona Per predicati arbitrari, il test sarebbe troppo lento

55 55 Gestore degli accessi E’ il modulo di piu’ basso livello del data manager Nei DBMS relazionali viene chiamato RSS (Relational Storage System) Effettua in pratica gli accessi alla BD Conosce l’organizzazione fisica delle pagine Conosce la disposizione delle tuple nelle pagine Usa un buffer manager per la gestione del trasferimento effettivo delle pagine

56 56 Indici Come si implementano Read e Write? Bisogna reperire i dati in Memoria di Massa A partire dal valore della chiave di una tupla, occorre trovare il record id –Record id = [pagina-id, offset-nella-pagina] Un indice collega i valori delle chiavi ai record id. –Le strutture indice piu’ comuni: tabelle hash e B-alberi

57 57 Hashing L’hashing usa una funzione H:V  B, dalle chiavi al numero del blocco (pagina) dove si trova il dato –V = matricola B = {1.. 1000} H(v) = v mod 1000 –se una pagina va in overflow, allora si deve aggiungere una lista di pagine extra –Al 90% di carico delle pagine, 1.2 accessi per richiesta! –ma, va male per accessi su intervalli (10 < v < 75)

58 58 B-albero KiKi PiPi K i+1 K1K1 P1P1 K n-1 PnPn... K´ i P´ i K´ i+1 K´ 1 P´ 1 K´ n-1 P´ n... Ogni nodo e' un sequence di coppie [puntatore, chiave] K 1 < K 2 < … < K n-2 < K n-1 P 1 punta a un nodo contenente chiavi < K 1 P i punta a un nodo contenente chiavi in intervallo [K i-1, K i ) P n punta a un nodo contenente chiavi > K n-1 Dunque, K ´ 1 < K ´ 2 < … < K ´ n-2 < K ´ n-1

59 59 Esempio n=3 127 496 14 83 221 352 127 145 189 221 245 320 521 690 352 353 487 Notare che le foglie sono ordinate per chiave, da sinistra a destra Importante: per ogni chiave, la foglia contiene il Record id della tupla, o la tupla stessa

60 60 Inserzione Per inserire la chiave v, si cerca la foglia dove v dovrebbe trovarsi: se c’e’ spazio, si inserisce Se no, si spezza la foglia in due, e si modifica il padre per prevedere i puntatori alle due foglie 19 -- 12 14 17 X 15 19 12 14 X 15 17 Per inserire la chiave 15 si spezza la foglia nel padre, [0, 19) diventa [0, 15) e [15, 19) se il padre e’ pieno, bisogna spezzarlo (in modo simile) l’albero resta automaticamente bilanciato

61 61 B-albero: Osservazioni L’algoritmo di cancellazione riunisce nodi adiacenti con riempimento < 50% La radice ed i nodi di livello uno sono mantenuti in una cache, per ridurre gli accessi a Indice secondario: le foglie contengono in realta’ coppie [chiave, record id] Indice primario: le foglie contengono i record

62 62 B+Alberi Ogni nodo foglia ha un puntatore al successivo facilita la ricerca su intervalli: trovata la prima chiave dell’intervallo, basta scorrere le foglie adiacenti mediante i puntatori 19 -- 12 14 17 P C X 15 19 12 14 X 15 17 P C´ C

63 63 B+Albero: ottimizzazione B+albero - ciascuna foglia ha un puntatore alla prossima, nell’ordine dato dalle chiavi Obbiettivo: ottimizzare interrogazioni il cui predicato di selezione definisce un intervallo di valori ammissibili Trovato il primo valore della chiave, si scandiscono sequenzialmente i nodi foglia

64 64 Database system Recovery Controllore dell’Affidabilita’ S. Costantini

65 65 Introduzione Un database puo’ divenire inconsistente a causa di: –fallimento di una transazione(abort) –errore di sistema (a volte causato da un OS crash) –media crash (disco corrotto) Il sistema di recovery assicura che il database contenga esattamente gli aggiornamenti prodotti dalle transazioni committed (cioe’ assicura atomicita’ e persistenza, nonostante i guasti )

66 66 Terminologia Affidabilita’ - il grado di certezza con il quale un sistema fornisce i risultati attesi su prove ripetute L’affidabilita’ si misura come mean-time-between-failures (MTBF) Disponibilita’ - frazione di tempo nel quale il sistema fornisce i risultati attesi. La disponibilita’ e’ ridotta anche dai tempi di riparazione e manutenzione preventiva Disponibilita’ = MTBF/(MTBF+MTTR), where MTTR is mean-time-to-repair

67 67 Terminologia (cont.) Failure (fallimento) - un evento dove il sistema dia risultati inattesi (sbagliati o mancanti) Fault (guasto) - causa identificata o ipotizzata di fallimento –Es. Un guasto nella scheda di memoria che causa un malfunzionamento del softwaren Transient fault - e’ occasionale, e non avviene nuovamente se si ritenta l’operazione Permanent fault - non-transient fault

68 68 Quali sono le cause di guasto? Il maggior problema e’ il software Environment - incendi, terremoti, vandalismi, mancanza di elettricita’, guasto al condizionatore system management - manutenzione, configurazione Tandem ‘89 Tandem ‘85 AT&T/ESS ‘85 Environment 7% 14% Hardware 8% 18% Subtotal 15% 32%20% system Mgmt 21% 42%30% Software 64% 25%50%

69 69 Assunzioni Two-phase locking, che mantiene i write locks fino a dopo il commit. Questo assicura –recoverability –no aborti a catena –strictness (non si utilizzano mai dati non committed) Gestione a livello di pagine –locks su pagine –il database e’ un insieme di pagine –le read e write operano su pagine

70 70 Modello della Memoria Memoria Stabile - resiste ai fallimenti di sistema Buffer (volatile) - contiene copie di alcune pagine, che vanno perse in caso di fallimenti Database Log Read, Write Fix, Flush Use, Unfix Buffer Manager Buffer Read, Write

71 71 Buffer Manager Fornisce primitive per accedere al buffer Fix carica una pagina nel buffer (la pagina diventa valida) Politica no-steal = mai deallocare pagine attive Use accede ad una pagina valida

72 72 Buffer Manager Unfix rende una pagina non piu’ valida Politica no-force = non riscrivere nel DB tutte le pagine attive al commit Flush periodicamente riscrive nel DB le pagine non piu’ valide Force trasferisce in modo sincrono una pagina dal buffer al DB (transazione sospesa fino a fine trasferimento)

73 73 Il LOG LOG: file sequenziale del gestore dell’affidabilità  scritto in memoria stabile  e’ una registrazione delle attivita’ del sistema

74 74 Checkpoint operazione periodica coordinata con buffer- manager  flush di tutte le pagine di transazioni terminate  registrazione identificatori transazioni in corso  non si accettano commit durante il checkpoint  si scrive in modo sincrono (force) l’elenco transazioni attive nel LOG  formato del record CKPT(T1,...,Tn)

75 75 DUMP copia completa del DB, fatta quando il sistema non è operativo (non ci sono transazioni attive)  copia memorizzata su memoria stabile (backup )  record di dump nel LOG  formato record DUMP(C) dove C è il dispositivo di backup

76 76 Organizzazione del LOG Record del LOG  di transazione  di sistema (checkpoint, DUMP) Record di TRANSAZIONE:  le transazioni registrano nel LOG le operazioni, nell’ordine in cui le effettuano  begin: record B(T)  commit/abortC(T), A(T)  T e’ l’identificatore della transazione

77 77 Organizzazione del LOG Record di UPDATE  identificatore transazione T  identificatore oggetto O  valore di O prima della modifica, before state  valore di O dopo la modifica, after state  U(T,O,BS,AS)

78 78 Organizzazione del LOG Record di DELETE  identificatore transazione T  identificatore oggetto O  valore di O prima della cancellazione, before state  D(T,O,BS)

79 79 Organizzazione del LOG Record di INSERT  identificatore transazione T  identificatore oggetto O  valore di O dopo l’inserzione, after state  I(T,O,AS)

80 80 UNDO e REDO  UNDO : si ricopia BS su O, –INSERT: si cancella O  REDO : si ricopia AS su O –DELETE: si cancella O  UNDO e REDO sono idempotenti  UNDO(UNDO(A)) = UNDO(A)  REDO(REDO(A)) = REDO(A) Utile se errori durante il ripristino

81 81 Gestione delle Transazioni  Regola WAL: Write Ahed Log BS scritta nel LOG prima di operare nella BD >>> permette UNDO operazioni se no commit  Regola Commit-Precedenza AS nel LOG prima del COMMIT >>> permette REDO operazioni se problema dopo commit (in no force)

82 82 Gestione delle Transazioni  Versione semplificata WAL + Commit-Precedenza: – record delle operazioni inseriti nel LOG prima di operare sulla BD, e prima del commit  GUASTO prima del commit: UNDO di tutte le operazioni di ogni transazione attiva mediante LOG  COMMIT/ABORT: la transazione scrive RECORD DI COMMIT/ABORT  GUASTO dopo il commit: REDO di tutte le operazioni della transazione mediante LOG

83 83 Gestione dei Guasti Guasto transitorio: perso il contenuto del buffer  resta il LOG –RIPRESA A CALDO (warm restart) Guasto permanente ad un disco:  resta il LOG (assunzione memoria stabile) –RIPRESA A FREDDO (cold restart)

84 84 Ripresa a caldo  Si cerca ultimo checkpoint nel LOG  Si decidono transazioni da rifare (insieme di REDO) e disfare (insieme di UNDO)  UNDO: transazioni attive al checkpoint  REDO: inizialmente vuoto  Si scorre il LOG:  B(T) => T in UNDO  C(T) => T in REDO  Si applicano UNDO e REDO

85 85 Ripresa a Freddo  Si usa l’ultimo DUMP per ripristinare uno stato stabile della BD  si ripercorre il LOG rifacendo tutte le azioni successive al DUMP  si fa ripresa a caldo dall’ultimo checkpoint

86 86 Ottimizzazioni User-Level Se la frequenza dei checkpoint si puo’ variare, regolarla mediante esperimenti Partitionare il DB su piu’ dischi per ridurre il tempo di restart

87 87 Media Failures Un media failure e’ la perdita di parte della memoria stabile La maggior parte dei dischi ha MTBF a piu’ di 10 anni, ma su 10 dischi... E’ importante avere dischi “shadow”, ossia un disco duplicato che faccia da copia “ombra’ della memoria stabile –Le Write vanno su entrambe le copie. –Le Read vanno su una sola copia (in alternanza, per efficienza)

88 88 RAID RAID - redundant array of inexpensive disks –Array ridondante di dischi di basso costo –Si basa su un array di N dischi in parallelo –Soluzione ancora piu’ sicura rispetto al disco ombra... M blocchi dati N-M blocchi di correzione errore

89 89 Dove Usare Dischi Ridondanti? Preferibilmente sia per il DB che per il LOG Ma almeno per il LOG –in un algoritmo di UNDO, e’ l’unico modo di avere before images sicure –in un algoritmo di REDO, e’ l’unico modo di avere after images sicure Se non si ha almeno un disco ombra per il LOG, il sistema ha un grosso punto debole

90 90 TP Monitors (Transaction Processing Monitors) Stefania Costantini

91 91 Architettura Client-Server Presentation Manager Workflow Control (gestisce le richieste) Database Server Front-End (Client) Back-End (Server) Utente finale Transaction Program richieste

92 92 Cosa fa un TP Monitor TP Monitor = Transaction Processing Monitor = Controllore dell’elaborazione delle Transazioni Una richiesta e’ un messaggio che descrive una unita’ di lavoro che il sistema deve eseguire. Un TP monitor coordina il flusso di richieste di esecuzione di transazioni provenienti da varie fonti (terminali e programmi applicativi)

93 93 Cosa fa un TP Monitor Struttura fondamentale: –Traduce l’input (proveniente da form/menu, o da un’istruzione in qualche linguaggio) in forma standard –Determina il tipo di transazione –Fa partire la transazione –Restituisce in forma opportuna l’output della transazione

94 94 Presentation Server Controllore di Workflow Transaction Server Rete Richieste Messaggio di richiesta Architettura 3-Tier di un TP Monitor Gli elementi dello schema possono essere distribuiti in rete Code

95 95 Architettura 3-Tier La struttura dell’applicazione ricalca la struttura del sistema Elementi del TP Monitor in un’architettura 3-Tier: –Presentation server : forms/menus, validazione degli input (password, connessione sicura) –Workflow controller : data una richiesta, produce la chiamata al programma corretto –Transaction server : esegue le richieste

96 96 Presentation Server Presentation independence - l’applicazione e’ indipendente dal tipo di dispositivo di i/o –terminale, ma anche telefono cellulare o lettore di codici a barre, o di carte di credito Il Presentation server ha due livelli: –Raccogliere gli input –Costruire le richieste

97 97 Autenticazione Autenticazione : determinare l’identita’ dell’utente e/o del dispositivo –Il sistema client puo’ effettuare l’autenticazione, che comunque il server effettua nuovamente (non si fida dei client) –Encryption della comunicazione client/server opportuno Occorrono funzioni di sistema per creare accounts, initializzare passwords, assegnare ore di accesso E’ una parte importante dello sviluppo di applicazioni TP

98 98 Workflow Controller Routing - Mappa il tipo di richiesta nel network id del server che potra’ elaborarla, e invia la risposta al client Gestisce errori ed eccezioni

99 99 Transaction Server Transaction server - programma applicativo che effettua il “real work” dell’elaborazione delle richieste Per portabilita’, e’ opportuno che sia scritto in un linguaggio di programmazione standard (C, C++, Java, COBOL) interfacciato con un Data Manipulation Language standard (SQL)

100 100 Basi di Dati e Web Stefania Costantini Basi di dati e Sistemi Informativi

101 101 Transazioni su Internet Web browser = presentation manager Messaggio dal web browser al server = richiesta di transazione su sistema (Transaction server) di cui si da’ l’URL http = protocollo di comunicazione client/server Web server = include il workflow controller 3-Tier su Web: –Presentation manager su client –Workflow controller su server –Transaction server molteplici, distribuiti su Internet

102 102 TP Monitor per Internet Il web server deve operare da workflow controller. I transaction server sono in generale remoti. Web browser Trad. URL Workflow Controller TP system Web Server Transaction Server DB Server TP monitors and DB servers attualmente sono sempre piu’ spesso integrati nei Web server

103 103 Architettura tradizionale Sistema/Programma dove si vuole eseguire la transazione : gateway CGI (Common gateway Interface): programma chiamato dal server CGI fornisce richiesta e parametri al gateway (nel nostro caso al TP system)