1 / 103

Tecnologia di un Database Server

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,

Télécharger la présentation

Tecnologia di un Database Server

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. 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. Implementazione del Locking S. Costantini

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

  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. 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. 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 • rli[x], rui[x], wli[x], wui[x] sono operazioni lock/unlock wl1[x] w1[x] rl2[x] r2[x] e’ impossibile • wl1[x] w1[x] wu1[x] rl2[x] r2[x] e’ OK

  8. Il Locking di base non basta • Non garantisce la serializzabilita’ • rl1[x] r1[x] ru1[x] wl1[y] w1[y] wu1[y] c1 rl2[y] r2[y] wl2[x] w2[x] ru2[y] wu2[x] c2 • Eliminando i lock operations, abbiamo r1[x] r2[y] w2[x] c2 w1[y] c1 che non e’ serializzabile • Possibile soluzione: ogni transazione acquisisce tutti i lock all’inizio • Problema: si limita troppo la concorrenza

  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, T2 e’ 2PL, ma non T1 perche’ ru1[x] precede wl1[y]

  10. Recoverability • Se Tk legge da Ti e Ti fa abort, Tk deve fare abort • Esempio - w1[x] r2[x] a1 vuol dire che T2 deve fare abort • Ma se Tk ha gia’ fatto commit? • Esempio - w1[x] r2[x] c2 a1 • T2 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 - w1[x] r2[x] c1 c2 • Non recoverable - w1[x] r2[x] c2 a1 • Si devono sincronizzare le operazioni

  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: w1[x] c1 r2[x] • permette cascading aborts: w1[x] r2[x] a1 • Un sistema che evita cascading aborts garantisce la recoverability.

  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 - w1[x,1] scrive il valore “1” in x. • w1[x,1] w1[y,3] c1 w2[y,1] r2[x] a2 • abort T2 : si ripristina la before image of w2[y,1], = 3 • Questo non e’ sempre possibile. • Ad esempio, consideriamo w1[x,2] w2[x,3] a1 a2 • a1 & a2 non e’ implementabile mediante before images • si noti che w1[x,2] w2[x,3] a2 a1 sarebbe stato OK

  13. Strictness • Un sistema stretto consente di eseguire ri[x] o wi[x] solo se tutte le transazioni precedenti che hanno scritto x hanno gia’ fatto commit o abort. • Esempi • stretto: w1[x] c1 w2[x] a2 • non stretto: w1[x] w2[x] … a1 a2 • stretto: w1[x] w1[y] c1 w2[y] r2[x] a2 • non stretto: w1[x] w1[y] … w2[y] a1 r2[x] a2 • “Stricness” implica “evitare cascading aborts.”

  14. 2PL e Recoverability • 2PL non garantisce la recoverability • La seguente esecuzione e’ non-recoverable, ma e’ 2PL wl1[x] w1[x] wu1[x] rl2[x] r2[x] c2 … c1 • 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. Brain Concurrency Control • Se l’utente legge su display un output della transazione Ti , e vuole usarlo come input per la transazione Tk, deve aspettare che Ti faccia commit prima di lanciare Tk. • Solo cosi’ e’ garantito che Ti venga effettivamente serializzata prima di Tk.

  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. 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. 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 Item Lista Locks Lista d’attesa x [T1,r] [T2,r] [T3,w] y [T4,w] [T5,w] [T6, r]

  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. 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. Deadlock • Un insieme di transazioni e’ in deadlock se ogni transazione e’ bloccata, e lo rimarra’ tutti’infinito se il sistema non interviene. • Esempio rl1[x] concesso rl2[y] concesso wl2[x] bloccata wl1[y] bloccata e deadlocked

  22. Deadlock • Con il deadlock, 2PL evita le esecuzioni non serializzabili: • Ad es. rl1[x] r1[x] rl2[y] r2[y] … w2[x] w1[y] • oppure (caso della perdita di update) rl1[x] r1[x] rl2[x] r2[x] … w2[x] w1[x] • Per eliminare il deadlock: abort di una transazione • rilascio del lock senza abortire: si viola il 2PL

  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,rl1[x] rl2[y] wl2[x] wl1[y], il sistema nega rl2[y]

  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. 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. 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. 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. 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. Ripartenza Ciclica • Le transazioni possono ripartire e abortire tutti’infinito. • T1 inizia. Poi T2 inizia. • vanno in deadlock, e T1 (la piu’ vecchia) e’ abortita. • T1 riparte, T2 continua, e vanno ancora in deadlock • T2 (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. 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. 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. Deadlock distribuito Nodo 2 • Il deadlock interessa due nodi. Il nodo singolo non puo’ rilevarlo Nodo 1 rl2[y] wl1[y] (bloccata) rl1[x] wl2[x] (bloccata) • La rilevazione tramite timeout e’ la piu’ usata

  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. 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. 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. MGL Grafi di Schema e istanza DB1 Database area A1 A2 F3 F1 F2 File Record R1.1 R1.2 R2.1 R2.2 R2.3 R2.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. 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 MGL Matrice di Compatibilita’ 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. 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. Modello Matematico del Locking • K lock per transazione • D lockable data items • N transazioni • T tempo tra richieste di lock • 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' K2N/2D. • La probabilita' di deadlock e' proporzionale a K4N/D2 • Prob(deadlock) / Prob(conflitto) = K2/D • Se K=10 e D = 106, allora K2/D = .0001

  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. 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. 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. 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. 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. 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. 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. 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. 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. Matr Nome Stipendio 123 null 1 Bill 100 175 123 1 Bill 125 134 null 2 Sue 120 199 134 2 Sue 140 227 null 27 Steve 80

  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. 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

More Related