© Giuseppe Berio – DI - UNITO Transazioni © Giuseppe Berio – DI - UNITO
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
© 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
© 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
© Giuseppe Berio – DI - UNITO Proprietà ACID A atomicity C consistency I isolation D durability © Giuseppe Berio – DI - UNITO
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
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
© 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 10000 Euro. © Giuseppe Berio – DI - UNITO
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
Aggiornamento fantasma P1 Passo P2 1 r (x) 2 x := x – 10 3 w (x) sum := 0 4 r (x) 5 r (y) 6 sum := sum +x 7 sum := sum + y 8 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
© Giuseppe Berio – DI - UNITO Lost Update P1 Passo P2 /* x = 100 */ r (x) 1 2 r (x) x := x+100 4 x := x+200 w (x) 5 /* 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
© Giuseppe Berio – DI - UNITO Dirty Read P1 Passo P2 r (x) 1 x := x + 100 2 w (x) 3 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
Letture inconsistenti P1 Passo P2 1 r (x) 2 x := x – 10 3 w (x) r (x) 4 5 6 x := x + 20 7 w (x) r (x) 8 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
Sequenzialità e Concorrenza Ipotesi (conti correnti): 500000 clienti, 30000 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
© 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
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
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
Gestire la serializzabilità con il Locking a due fasi © Giuseppe Berio – DI - UNITO
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 := 0 10 Lock(x,r) 11 Lock(y,r) 12 r (x) 13 r (y) 14 sum := sum +x 15 sum := sum + y 16 Unlock(x) 17 Unlock(y) 18 Fase 1 Fase 2 © Giuseppe Berio – DI - UNITO
© 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
Un problema aggiuntivo: il fantasma Emp Jones Service Clerk 20000 Meier Service Clerk 22000 Paulus Service Manager 42000 Smyth Toys Cashier 25000 Brown Sales Clerk 28000 Albert Sales Manager 38000 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
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
Controllo della Concorrenza in Oracle Controllo della concorrenza multiversione; transazioneT1 transazione T2 Snapshot 2 Snapshot 1 dato first commiter wins © Giuseppe Berio – DI - UNITO
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
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
© 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