La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

© Giuseppe Berio – DI - UNITO1 Transazioni. © Giuseppe Berio – DI - UNITO2 La Metodologia adottata nel Corso Determinazione requisiti Specifica dei requisiti.

Presentazioni simili


Presentazione sul tema: "© Giuseppe Berio – DI - UNITO1 Transazioni. © Giuseppe Berio – DI - UNITO2 La Metodologia adottata nel Corso Determinazione requisiti Specifica dei requisiti."— Transcript della presentazione:

1 © Giuseppe Berio – DI - UNITO1 Transazioni

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

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

4 © Giuseppe Berio – DI - UNITO4 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

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

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

7 © Giuseppe Berio – DI - UNITO7 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

8 © Giuseppe Berio – DI - UNITO8 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) (a)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) (a)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.

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

10 © Giuseppe Berio – DI - UNITO10 Aggiornamento fantasma P1PassoP2 1r (x) 2x := x – 10 3w (x) sum := 0 4 r (x) 5 r (y) 6 sum := sum +x 7 sum := sum + y 8 9r (y) 10y := y w (y) somma sbagliata Osservazioni: il problema è l’interleaving r 2 (x) w 2 (x) r 1 (x) r 1 (y) r 2 (y) w 2 (y) il problema non sorge se l’esecuzione è sequenziale schedule

11 © Giuseppe Berio – DI - UNITO11 Lost Update P1PassoP2 /* x = 100 */ r (x) 1 2r (x) x := x+100 4x := x+200 w (x) 5 /* x = 200 */ 6w (x) /* x = 300 */ update “lost” Osservazione: il problema è l’interleaving r 1 (x) r 2 (x) w 1 (x) w 2 (x) il problema non sorge se l’esecuzione è sequenziale

12 © Giuseppe Berio – DI - UNITO12 Dirty Read P1PassoP2 r (x) 1 x := x w (x) 3 4r (x) 5x := x failure & rollback 6 7w (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

13 © Giuseppe Berio – DI - UNITO13 P1PassoP2 1r (x) 2x := x – 10 3w (x) r (x) 4 5 6x := x w (x) r (x) 8 Non legge il medesimo valore Osservazioni: il problema è l’interleaving r 2 (x) w 2 (x) r 1 (x) w 2 (x) r 1 (x) il problema non sorge se l’esecuzione è sequenziale Letture inconsistenti

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

15 © Giuseppe Berio – DI - UNITO15 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à

16 © Giuseppe Berio – DI - UNITO16 Livelli di Isolamento SQL 92 LivelloLetture Sporche Letture inconsistenti Fantasma Read uncommitted Si Read committed NoSi Repeatable read No Si SerializableNo SQL92SQL92

17 © Giuseppe Berio – DI - UNITO17 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

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

19 © Giuseppe Berio – DI - UNITO19 Funzionamento del locking a due fasi P1PassoP2 1Lock(x,w) r (x) 2x := x – 10 3w (x) 4Lock(y,w) 5r (y) 6y := y w (y) 8Unlock(x) 9Unlock(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

20 © Giuseppe Berio – DI - UNITO20 Deadlock P1TimeP2 1Lock(y,w) Lock(x,w)2 Lock(y,w)3 4Lock(x,w)

21 © Giuseppe Berio – DI - UNITO21 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: (a)Delete From Emp Where Department = ‘Service’ And Position = ‘Manager’ (b)Insert Into Emp Values (‘Smith’, ‘Service’, ‘Manager’, 40000) (c)Update Emp Set Department = ‘Sales’ Where Department = ‘Service’ And Position <> ‘Manager’ (d)Insert Into Emp Values (‘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 Un problema aggiuntivo: il fantasma

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

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

24 © Giuseppe Berio – DI - UNITO24 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

25 © Giuseppe Berio – DI - UNITO25 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

26 © Giuseppe Berio – DI - UNITO26 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 begin update Merce set quantitàdiponibile=quantitàdisponibile-qt2 where tipo=2; update OrdiniTipo2 set stato='evaso' where codordine=ilcodordine; exception when others then RAISE MerceInsufficente; end; if qt3<> 0 then begin update Merce set quantitàdiponibile=quantitàdisponibile-qt3 where tipo=3; update OrdiniTipo3 set stato='evaso' where codordine=ilcodordine; exception when others then RAISE MerceInsufficente; end; Commit; Exception when MerceInsufficente then begin rollback; :riprovare:='riprovare'; end; when others then rollback; end; / 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;


Scaricare ppt "© Giuseppe Berio – DI - UNITO1 Transazioni. © Giuseppe Berio – DI - UNITO2 La Metodologia adottata nel Corso Determinazione requisiti Specifica dei requisiti."

Presentazioni simili


Annunci Google