tecnologia di un database server
DESCRIPTION
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, - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/1.jpg)
1
Tecnologia di un Database Server
S. CostantiniDispensa 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/
![Page 2: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/2.jpg)
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.
![Page 3: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/3.jpg)
3
Implementazione del Locking
S. Costantini
![Page 4: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/4.jpg)
4
Modello di un SistemaTransazione 1 Transazione N
DatabaseServer
Bot,SQL QueriesCommit, Abort
Ottimizzatore QueryEsecutore Query
SchedulerBuffer Manager
Recovery manager
Database
![Page 5: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/5.jpg)
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
![Page 6: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/6.jpg)
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
![Page 7: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/7.jpg)
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
![Page 8: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/8.jpg)
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, abbiamor1[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
![Page 9: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/9.jpg)
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]
![Page 10: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/10.jpg)
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
![Page 11: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/11.jpg)
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.
![Page 12: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/12.jpg)
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
![Page 13: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/13.jpg)
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.”
![Page 14: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/14.jpg)
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
![Page 15: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/15.jpg)
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.
![Page 16: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/16.jpg)
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
![Page 17: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/17.jpg)
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
![Page 18: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/18.jpg)
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]
![Page 19: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/19.jpg)
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
![Page 20: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/20.jpg)
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.
![Page 21: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/21.jpg)
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
![Page 22: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/22.jpg)
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
![Page 23: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/23.jpg)
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]
![Page 24: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/24.jpg)
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.
![Page 25: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/25.jpg)
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
![Page 26: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/26.jpg)
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
![Page 27: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/27.jpg)
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.
![Page 28: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/28.jpg)
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).
![Page 29: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/29.jpg)
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
![Page 30: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/30.jpg)
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.
![Page 31: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/31.jpg)
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
![Page 32: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/32.jpg)
32
Deadlock distribuito• Il deadlock interessa due nodi.
Il nodo singolo non puo’ rilevarlo
• La rilevazione tramite timeout e’ la piu’ usata
rl1[x]wl2[x] (bloccata)
Nodo 1
rl2[y]wl1[y] (bloccata)
Nodo 2
![Page 33: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/33.jpg)
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
![Page 34: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/34.jpg)
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
![Page 35: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/35.jpg)
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
![Page 36: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/36.jpg)
36
MGL Grafi di Schema e istanzaDatabase
area
File
Record
DB1
A1 A2
F1 F2 F3
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)
![Page 37: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/37.jpg)
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 conintenzione di write,per scansione cheaggiorna alcunidei 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.
![Page 38: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/38.jpg)
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.
![Page 39: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/39.jpg)
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' 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
• K lock per transazione• D lockable data items
• N transazioni• T tempo tra richieste di lock
![Page 40: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/40.jpg)
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.
![Page 41: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/41.jpg)
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
![Page 42: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/42.jpg)
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
![Page 43: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/43.jpg)
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
![Page 44: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/44.jpg)
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
![Page 45: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/45.jpg)
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
![Page 46: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/46.jpg)
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
![Page 47: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/47.jpg)
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
![Page 48: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/48.jpg)
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 Stipendio123 null 1 Bill 100175 123 1 Bill 125134 null 2 Sue 120199 134 2 Sue 140227 null 27 Steve 80
![Page 49: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/49.jpg)
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
![Page 50: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/50.jpg)
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
![Page 51: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/51.jpg)
51
Fantasmi• Problemi nell’uso di 2PL con inserire e delete
T1: Read Conti 1, 2, e 3T2: inserire Conti[4, Ancona, 100]T2: Read Sedi(Ancona), restituisce 500T2: Write Sedi(Ancona, 600)T1: Read Sedi(Ancona), restituisce 600T1: Commit
N# Sede Totale Luogo Totale1 Pescara 4002 Ancona 2003 Ancona 300
Pescara 400Ancona 500
Conti Sedi
il record fantasma
![Page 52: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/52.jpg)
52
Il problema del fantasma• T1 dovrebbe fare lock sul record 4, che non c’e’!
• Quale delle operazioni di T1 determina che ci sono solo 3 record?– Read end-di-file?– Read del numero dei record?– SQL Select?
• L’operazione in conflitto con T2 e’ esattamente inserire Conti[4,Ancona,100]
• Quindi, inserire conti[4,Ancona,100] dovrebbe essere eseguita dopo il commit di T1
![Page 53: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/53.jpg)
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
![Page 54: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/54.jpg)
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. T1 pone un read lock su tutti i record con Sede = “Ancona”
– Conflitto con write lock di T2 che appunto vuole scrivere un record con Sede = Ancona
• Per predicati arbitrari, il test sarebbe troppo lento
![Page 55: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/55.jpg)
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
![Page 56: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/56.jpg)
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
![Page 57: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/57.jpg)
57
Hashing• L’hashing usa una funzione H:VB, 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)
![Page 58: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/58.jpg)
58
B-albero
Ki Pi Ki+1K1 P1 Kn-1 Pn. . . . . .
K´i P´i K´i+1K´1 P´1 K´n-1 P´n. . . . . .
• Ogni nodo e' un sequence di coppie [puntatore, chiave]
• K1 < K2 < … < Kn-2 < Kn-1
• P1 punta a un nodo contenente chiavi < K1
• Pi punta a un nodo contenente chiavi in intervallo [Ki-1, Ki)
• Pn punta a un nodo contenente chiavi > Kn-1
• Dunque, K ´1 < K ´2 < … < K ´n-2 < K ´n-1
![Page 59: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/59.jpg)
59
Esempio n=3127 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
![Page 60: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/60.jpg)
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 17X
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 automaticamentebilanciato
![Page 61: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/61.jpg)
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
![Page 62: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/62.jpg)
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
CX
15 19
12 14
X
15 17
P
C´C
![Page 63: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/63.jpg)
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
![Page 64: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/64.jpg)
64
Database system Recovery
Controllore dell’Affidabilita’
S. Costantini
![Page 65: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/65.jpg)
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 )
![Page 66: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/66.jpg)
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
![Page 67: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/67.jpg)
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
![Page 68: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/68.jpg)
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 ‘85Environment 7% 14%Hardware 8% 18% Subtotal 15% 32% 20%system Mgmt 21% 42% 30%Software 64% 25% 50%
![Page 69: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/69.jpg)
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
![Page 70: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/70.jpg)
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
DatabaseLog
Read, Write
Fix, FlushUse, Unfix
Buffer Manager
Buffer
Read, Write
![Page 71: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/71.jpg)
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
![Page 72: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/72.jpg)
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)
![Page 73: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/73.jpg)
73
Il LOG
• LOG: file sequenziale del gestore dell’affidabilità
scritto in memoria stabile e’ una registrazione delle attivita’ del
sistema
![Page 74: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/74.jpg)
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)
![Page 75: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/75.jpg)
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
![Page 76: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/76.jpg)
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/abort C(T), A(T) T e’ l’identificatore della transazione
![Page 77: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/77.jpg)
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)
![Page 78: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/78.jpg)
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)
![Page 79: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/79.jpg)
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)
![Page 80: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/80.jpg)
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
![Page 81: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/81.jpg)
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)
![Page 82: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/82.jpg)
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
![Page 83: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/83.jpg)
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)
![Page 84: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/84.jpg)
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
![Page 85: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/85.jpg)
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
![Page 86: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/86.jpg)
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
![Page 87: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/87.jpg)
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)
![Page 88: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/88.jpg)
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
![Page 89: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/89.jpg)
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
![Page 90: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/90.jpg)
90
TP Monitors(Transaction Processing Monitors)
Stefania Costantini
![Page 91: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/91.jpg)
91
Architettura Client-Server
Presentation Manager
Workflow Control(gestisce le richieste)
Database Server
Front-End(Client)
Back-End(Server)
Utente finale
Transaction Program
richieste
![Page 92: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/92.jpg)
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)
![Page 93: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/93.jpg)
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
![Page 94: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/94.jpg)
94
Presentation Server
Controllore di Workflow
Transaction Server Transaction Server
Rete
Richieste
Messaggiodi richiesta
Architettura 3-Tierdi un TP Monitor
• Gli elementi dello schema possono essere distribuiti in rete
Code
![Page 95: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/95.jpg)
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
![Page 96: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/96.jpg)
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
![Page 97: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/97.jpg)
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
![Page 98: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/98.jpg)
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
![Page 99: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/99.jpg)
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)
![Page 100: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/100.jpg)
100
Basi di Dati e Web
Stefania CostantiniBasi di dati e Sistemi Informativi
![Page 101: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/101.jpg)
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
![Page 102: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/102.jpg)
102
TP Monitor per Internet• Il web server deve operare da workflow controller. I
transaction server sono in generale remoti.
Webbrowser
Trad. URLWorkflowController
TP system
Web Server
TransactionServer
DB Server
• TP monitors and DB servers attualmente sono sempre piu’ spesso integrati nei
• Web server
![Page 103: Tecnologia di un Database Server](https://reader036.vdocuments.site/reader036/viewer/2022081519/56812bc5550346895d900b3b/html5/thumbnails/103.jpg)
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)