© Giuseppe Berio – DI - UNITO

Presentazione sul tema: "© Giuseppe Berio – DI - UNITO"— Transcript della presentazione:

1 © Giuseppe Berio – DI - UNITO
Transazioni © Giuseppe Berio – DI - UNITO

2 basedati centralizzata
La Metodologia adottata nel Corso Mission Statement + Glossario Lista Funzionalià 3 Descrizione Funzionalità 6 Codice Transazioni In PL/SQL 1 2 4 5 Schema concettuale EA Schema Logico Relazionale Schema Fisico Architettura: basedati centralizzata 7 Verifica & Validazione Determinazione requisiti Specifica dei requisiti Progetto Implementazione 1 2,3 4 5,6 © Giuseppe Berio – DI - UNITO

3 © Giuseppe Berio – DI - UNITO
Contenuti Elementi preliminari Problemi canonici della concorrenza della transazioni nei DBMS Programmazione di transazioni in PL/SQL © Giuseppe Berio – DI - UNITO

4 © Giuseppe Berio – DI - UNITO
Transazioni: Motivi Affidabilità protezione da malfunzionamenti (hardware, e del software di base con perdita dei dati nelle memorie centrali) Impedire che programmi possano effettuare “modifiche parziali” su una basedati dovute, ad esempio, a vincoli di integrità non verificati, ad errori durante l’esecuzione dei programmi stessi Controllo della concorrenza Impedire, ragionevolmente, l’uso di dati non completamente elaborati o incerti dovuti all’esecuzione concorrente di più programmi su una basedati A C I D © Giuseppe Berio – DI - UNITO

5 © Giuseppe Berio – DI - UNITO
Proprietà ACID A atomicity C consistency I isolation D durability © Giuseppe Berio – DI - UNITO

6 Architettura di un DBMS Relazionale
Gestore autorizzazioni Gestore catalogo Ottimizzatore Esecutore piani d’accesso Gestore accesso Gestore strutture di memorizzazione Gestore affidabilità Gestore concorrenza Gestore buffer Gestore memoria permanente Moduli di gestione delle transazioni Dati © Giuseppe Berio – DI - UNITO

7 Definizione di Transazione in ambiente relazionale
Una transazione è una sequenza d’istruzioni (in SQL) su una basedati, con un inizio ed una fine In generale, la fine della transazione può essere esplicita attraverso le due istruzioni seguenti: Commit Rollback L’istruzione di rollback può essere implicita cioè eseguita dal DBMS e non parte della transazione © Giuseppe Berio – DI - UNITO

8 © Giuseppe Berio – DI - UNITO
Database Voli e Prenotazioni Tratte(NumVolo, Da, A, ora-partenza, ora-arrivo) Voli(NumVolo, DataVolo, aeroplano, posti-totali) Tariffe-disponibili(id-tariffa, NumVolo, DataVolo, num-posti, prezzo) Prenotazioni(id-prenotazione, id-passeggero, NumVolo, DataVolo, prezzo) Transazione che prenota, per un dato cliente, un posto di minor prezzo nel volo 13 per il 13 Luglio. (b) Transazione che stampa un rapporto contenente per ogni volo la percentuale di posti che sono prenotati e il guadagno totale. Database Conti Bancari e Clienti Clienti(cod-fiscale, nome-cognome, indirizzo, citta’, cap, telefono, stato) Conti(num-conto, cod-fiscale, saldo) Operazioni(num-conto, num-operazione, data-operazione, somma, sportello) Transazione che deposita una somma di denaro su un determinato conto corrente. (b) Transazione che trasferisce soldi da un conto corrente ad un altro. (c) Transazione che trova la somma dei prelievi relativi ad uno specifico sportello (automatico o meno). (d) La transazione che stampa la lettera (la quale informa di un nuovo tipo di conto) per ogni cliente la cui somma dei saldi di ciascun conto supera Euro. © Giuseppe Berio – DI - UNITO

9 Fondamenti della teoria della gestione della concorrenza
Update Emp Set Department = ‘Sales’ Where code=567 Update Emp Set Department = ‘Sales’ Where code=567 W(t) R(t) Update Emp Set Department = ‘Sales’ Where Department = ‘Service’ And Position <> ‘Manager’ R(t1) R(t2)…. W(t1) W(t2)…. © Giuseppe Berio – DI - UNITO

10 Aggiornamento fantasma
P1 Passo P2 1 r (x) 2 x := x – 10 3 w (x) sum := r (x) r (y) sum := sum +x sum := sum + y 9 r (y) 10 y := y + 10 11 w (y) schedule somma sbagliata Osservazioni: il problema è l’interleaving r2(x) w2(x) r1(x) r1(y) r2(y) w2(y) il problema non sorge se l’esecuzione è sequenziale © Giuseppe Berio – DI - UNITO

11 © Giuseppe Berio – DI - UNITO
Lost Update P1 Passo P2 /* x = 100 */ r (x) 2 r (x) x := x x := x+200 w (x) /* x = 200 */ 6 w (x) /* x = 300 */ update “lost” Osservazione: il problema è l’interleaving r1(x) r2(x) w1(x) w2(x) il problema non sorge se l’esecuzione è sequenziale © Giuseppe Berio – DI - UNITO

12 © Giuseppe Berio – DI - UNITO
Dirty Read P1 Passo P2 r (x) x := x w (x) 4 r (x) 5 x := x - 100 failure & rollback 6 7 w (x) non può assicurare la validità dei dati letti Osservazione: il rollback di una transazione incide sulle transazioni concorrenti il problema non sorge se l’esecuzione è sequenziale © Giuseppe Berio – DI - UNITO

13 Letture inconsistenti
P1 Passo P2 1 r (x) 2 x := x – 10 3 w (x) r (x) 5 6 x := x + 20 7 w (x) r (x) Non legge il medesimo valore Osservazioni: il problema è l’interleaving r2(x) w2(x) r1(x) w2(x) r1(x) il problema non sorge se l’esecuzione è sequenziale © Giuseppe Berio – DI - UNITO

14 Sequenzialità e Concorrenza
Ipotesi (conti correnti): clienti, transazioni di richiesta deposito, Necessario capire cosa deve essere concorrente e cosa deve essere sequenziale: teoria della concorrenza Un cliente potrebbe attendere: 30000*0,1’’=3000’’ 30000*0,01’’=300’’ 30000*0,001’’=30’’ © Giuseppe Berio – DI - UNITO

15 © Giuseppe Berio – DI - UNITO
Serializzabilità Dato un qualunque schedule tra due o più transazioni, si dice serializzabile sse il risultato della sua esecuzione è uguale ad uno schedule sequenziale delle transazioni Uno schedule relativo a un insieme di transazioni è sequenziale sse corrisponde all’esecuzione in una certa sequenza della transazioni stesse La serializzabilità non coincide con la sequenzialità © Giuseppe Berio – DI - UNITO

16 Livelli di Isolamento SQL 92
Livello Letture Sporche Letture inconsistenti Fantasma Read uncommitted Si Read committed No Repeatable read Serializable SQL 92 © Giuseppe Berio – DI - UNITO

17 Realizzazione del Controllo della Concorrenza nei DBMS
Controllo ottimistico La probabilità di dover annullare ciò che è stato fatto poiché non si ha serializzabilità è bassa Efficiente Controllo pessimistico La probabilità di dover annullare ciò che è stato fatto poiché non si ha serializzabilità è alta Molto sicuro © Giuseppe Berio – DI - UNITO

18 Gestire la serializzabilità con il Locking a due fasi
© Giuseppe Berio – DI - UNITO

19 Funzionamento del locking a due fasi
P1 Passo P2 1 Lock(x,w) r (x) 2 x := x – 10 3 w (x) 4 Lock(y,w) 5 r (y) 6 y := y + 10 7 w (y) 8 Unlock(x) 9 Unlock(y) sum := Lock(x,r) Lock(y,r) r (x) r (y) sum := sum +x sum := sum + y Unlock(x) Unlock(y) Fase 1 Fase 2 © Giuseppe Berio – DI - UNITO

20 © Giuseppe Berio – DI - UNITO
Deadlock P1 Time P2 1 Lock(y,w) Lock(x,w) 2 Lock(y,w) 3 4 Lock(x,w) © Giuseppe Berio – DI - UNITO

21 Un problema aggiuntivo: il fantasma
Emp Jones Service Clerk Meier Service Clerk Paulus Service Manager Smyth Toys Cashier Brown Sales Clerk Albert Sales Manager Name Department Position Salary Update transaction t: Delete From Emp Where Department = ‘Service’ And Position = ‘Manager’ Insert Into Emp Values (‘Smith’, ‘Service’, ‘Manager’, 40000) (c) Update Emp Set Department = ‘Sales’ And Position <> ‘Manager’ (‘Stone’, ‘Service’, ‘Clerk’, 13000) Retrieval transaction q: Select Name, Position, Salary From Emp Where Department = ‘Service’ Retrieval transaction p: Select Name, Position, Salary From Emp Where Department = ‘Sales’ Osservazioni: Interleaving di q e t produce un cosiddetto fantasma Mettere un lock sui record nelle tabelle non risolve il problema ma è necessario passare ad un lock su predicato © Giuseppe Berio – DI - UNITO

22 Gestione dell’affidabilità (in breve)
Transazione: Delete From Emp Where Department = ‘Service’ And Position = ‘Manager’ Commit; Controllo della concorrenza Gestore dell’affidabilità File di log (del, BeforeState(p1!)); ….; (del, BeforeState(pn!))….commit; Dati © Giuseppe Berio – DI - UNITO

23 Controllo della Concorrenza in Oracle
Controllo della concorrenza multiversione; transazioneT1 transazione T2 Snapshot 2 Snapshot 1 dato first commiter wins © Giuseppe Berio – DI - UNITO

24 Programmazione di Transazioni
Una transazione è programmata attraverso una serie di istruzioni SQL, in un qualche linguaggio di programmazione (e con un certo approccio) E’ quindi necessario distinguere tra: il programma attraverso cui si programma(no) la(e) transazione(i) la singola transazione Ciò implica anche la distinzione del concetto di terminazione che può essere del programma della transazione © Giuseppe Berio – DI - UNITO

25 Introduzione al PL/SQL
Un linguaggio di programmazione completo di tutte le istruzioni e strutture dati di un linguaggio di programmazione imperativo Permette di usare select, update, delete e insert nel programma Permette di usare commit e rollback nel programma Ipotizza un controllo ottimistico della concorrenza Usa le eccezioni per gestire eventuali problemi che possono sorgere nell’esecuzione di un’istruzione Progettato anche per ORACLE come ORDBMS © Giuseppe Berio – DI - UNITO

26 © Giuseppe Berio – DI - UNITO
if qt1<> 0 then begin update Merce set quantitàdiponibile=quantitàdisponibile-qt1where tipo=1; update OrdiniTipo1 set stato='evaso' where codordine=ilcodordine; exception when others then RAISE MerceInsufficente; end; if qt2<> 0 then update Merce set quantitàdiponibile=quantitàdisponibile-qt2 where tipo=2; update OrdiniTipo2 set stato='evaso' where codordine=ilcodordine; if qt3<> 0 then update Merce set quantitàdiponibile=quantitàdisponibile-qt3 where tipo=3; update OrdiniTipo3 set stato='evaso' where codordine=ilcodordine; Commit; Exception when MerceInsufficente then begin rollback; :riprovare:='riprovare'; end; when others then rollback; / print(riprovare); (SQLPLUS) variable riprovare varchar; (SQLPLUS) Declare ilcodordine varchar2(5); qt1,qt2,qt3 number(6); MerceInsufficente Exception;   begin begin select quantitàordinata into qt1 from OrdiniTipo1 where codordine=ilcodordine; exception when no_data_found then qt1:=0; end; begin select quantitàordinata into qt2 from OrdiniTipo2 where codordine=ilcodordine; exception when no_data_found then qt2:=0; end; begin select quantitàordinata into qt3 from OrdiniTipo3 where codordine=ilcodordine; exception when no_data_found then qt3:=0; end; © Giuseppe Berio – DI - UNITO