Basi di Dati e Sistemi Informativi

Basi di Dati e SistemiInformativi Struttura di un DBMS: GestionedelleTransazioni Home page del corso: http://www.cs.unibo.it/~difelice/dbsi/

GestionedelleTransazioni • Transazione sequenza di operazioni SQL la cui esecuzionedeveavveniregarantendoalcunecaratteristiche di correttezza, isolamento e robustezza. • Unatransazionetermina con commit ( “procedi”) o con abort ( “annulla”). • Definite dall’utente, tramitecomandi SQL: • start transaction … end transaction. • Definite automaticamentedal sistema.

GestionedelleTransazioni PROPRIETA’ ACIDE DELLE TRANSAZIONI Atomicita’  La transazionedeveessereeseguita con la regola del “tuttoo niente”. Consistenza La transazionedevelasciareil DB in unostatoconsistente, eventualivincoli di integrita’ non devonoessereviolati. Isolamento  L’esecuzione di unatransazionedeveessereindipendentedallealtre. Persistenza  L’effetto di unatransazioneche ha fattocommit non deveessereperso.

GestionedelleTransazioni • Gestoredellaconsistenza tipicamenteimplementatadaicompilatori del DDL. • Prima di eseguireun’istruzione SQL, ilsuoeffettovienesimulato. • Si verificachetuttiivincoli di integrita’ sianorispettati, in casocontrariosi genera un errore e sibloccal’esecuzionedell’istruzionecorrente.

Gestore di Interrogazioni e aggiornamenti Gestoredelle transazioni Gestoredellaconcorrenza Gestoredei metodid’accesso Gestoredella affidabilità Gestore del buffer Gestoredella memoriasecondaria Memoria secondaria GestionedelleTransazioni • Gestoredelleaffidabilita’  garantisceatomicita’ e persistenzadelletransazioni. • Gestoredellaconcorrenza garantiscel’isolamentodelletransazioni.

Gestore di Interrogazioni e aggiornamenti Gestoredelle transazioni Gestoredellaconcorrenza Gestoredei metodid’accesso Gestoredella affidabilità Gestore del buffer Gestoredella memoriasecondaria Memoria secondaria GestionedelleTransazioni • Gestoredelleaffidabilita’ garantisceatomicita’ e persistenzadelletransazioni. • Gestoredellaconcorrenza garantiscel’isolamentodelletransazioni.

GestionedelleTransazioni • Gestoredel’affidabilita’  verificachesianogarantite le proprieta’ di atomicita’ e persistenzadelletransazioni. • Responsabile di implementareicomandi di: start transaction, commit, rollback • Responsabile di ripristinareilsistemadopomalfunzionamentisoftware (ripresa a caldo) • Responsabile di ripristinareilsistemadopomalfunzionamenti hardware (ripresa a freddo)

GestionedelleTransazioni Il controllore di affidabilita’ utilizza un log, nel quale sono indicate tutte le operazionisvolte dal DBMS. LOG, strutturafisica <10:34, 11/12/2012, Transaction: T1, INSERT(3,Mario, Rossi) INTO IMPIEGATI> <10:35, 11/12/2012, Transaction: T2, DELETE(3,Mario, Rossi) INTO IMPIEGATI> <10:36, 11/12/2012, Transaction: T3, INSERT(6,Maria, Bianchi) INTO IMPIEGATI>

GestionedelleTransazioni Il controllore di affidabilita’ utilizza un log, nel quale sono indicate tutte le operazionisvolte dal DBMS. LOG, strutturalogica 10:36 10:34 10:35 Time T3, INSERT T1, INSERT T2, DELETE Tramiteil log, e’ possibile fare do/undo delletransazioni …

GestionedelleTransazioni • Tramiteil log, e’ possibileripristinare lo statocompleto del DBMS in caso di malfunzionamenti/guasti … a pattoche non sianopersiancheidati del log! • Si assume cheidati del log sianomemorizzatisumemoria stabile (astrazione!). • Si possonousare opportune tecnologie per aumentarel’affidabilita’ RAID (Redundant Array of Independent Disks)

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Due tipi di record: Record di transizione tengonotracciadelle operazionisvolte da ciascunatransizionesul DBMS. Record di sistema tengonotracciadelle operazioni di sistema (dump/checkpoint).

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Record di begin, commit, abort: tengonotraccia del tipo di operazione e del nome (univoco) dellatransazione. B(T),C(T),B(T2),C(T2),B(T3),A(T3), etc

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Record di update: tengonotraccia del del nome (univoco) dellatransazione, dell’oggettomodificato(O), dellostatoprecedente (BS) e dellostatoattuale(AS). U(T,O,BS,AS) -> U(T1,”CONTO”,4,5)

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Record di insert: tengonotraccia del del nome (univoco) dellatransazione, dell’oggettomodificato(O), dellostatoattuale(AS). I(T,O,AS) -> I(T1,”CONTO”,1000)

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Record di delete: tengonotraccia del del nome (univoco) dellatransazione, dell’oggettomodificato(O), dellostatoprecedente(BS). D(T,O,BS) -> D(T1,”CONTO”,1000)

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time • Ricapitolando, irecord delletransazionisono del tipo: • B(T), C(T), A(T) • U(T, O, BS, AS), • I(T, O, AS) • D(T,O,BS)

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Due tipi di record: Record di transizione tengonotracciadelle operazionisvolte da ciascunatransizionesul DBMS. Record di sistema tengonotracciadelle operazioni di sistema (dump/checkpoint).

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Record di dump: tengonotracciadeglieventi di backup completodella base di datisumemoria stabile. Talieventisonoeffettuati con unacertaperiodicita’ definitadall’amministratore del sistema. DUMP(DB)

GestionedelleTransazioni Il log sipresenta come un file sequenzialesuddiviso in record: Time Record di checkpoint: tengonotracciadelletransazioniattivepresentinelsistema. Transazioneattiva  transazioneche non si e’ ancoraconclusacon un’azione di commit o rollback. CK(T1,T2,T3 …, Tn)

GestionedelleTransazioni Per aumentarel’efficienzaprestazionale, tuttii DBMS utilizzano un buffer temporaneodi informazioni in memoriaprincipale, il quale vieneperiodicamente scrittosumemoriasecondaria. RS Gestore del buffer (modulo del DBMS) RAM HD Buffer del DBMS DBMS

GestionedelleTransazioni Quandosieffettua un checkpoint: Si sospendonotutte le operazioni in corsosul DBMS. Si rendonoeffettiveanchesumemoriasecondariatutte le operazionieffettuate da transazionichehannofattocommit, i cui datisitrovinoancoranel buffer (flush). Si scrivononel record di checkpoint del log tuttele transazioniattivedel sistema. Si riprendel’esecuzionedelleoperazioni.

GestionedelleTransazioni REGOLE di SCRITTURA del LOG • Regola Write Ahead Log  la parte BS (before state) di ogni record di log deveesserescritta prima che la corrispondenteoperazionevengaeffettuatanella base di bati. • In pratica: I record di log devonoesserescritti prima dellecorrispondentioperazionisulla base di dati, in modo da poter fare undodelleoperazioni!

GestionedelleTransazioni REGOLE di SCRITTURA del LOG • Regola di Commit Precedence la parte AS (after state) di ogni record di log deveesserescrittanel log prima di effettuareilcommitdellatransazione. • In pratica: I record di log devonoesserescritti prima di effettuarel’operazione di commit, in modo da potergarantireilredo di unatransazione non ancorascrittasumemoriasecondaria.

GestionedelleTransazioni ESEMPI di SCHEDULING di OPERAZIONI I(T,X,AS) I(T,Y,AS) C(T) B(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(Y) w(X) • Regola Write Ahead Log  OK • Regola Commit Precedence  OK

GestionedelleTransazioni ESEMPI di SCHEDULING di OPERAZIONI I(T,Y,AS) I(T,X,AS) C(T) B(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(X) w(Y) • Regola Write Ahead Log  NO! • Regola Commit Precedence  OK

GestionedelleTransazioni ESEMPI di SCHEDULING di OPERAZIONI I(T,X,AS) I(T,Y,AS) C(T) B(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(X) w(Y) • Regola Write Ahead Log  OK • Regola Commit Precedence  OK

GestionedelleTransazioni ESEMPI di SCHEDULING di OPERAZIONI I(T,X,AS) I(T,Y,AS) C(T) B(T) SCRITTURE SUL LOG SCRITTURE SUL DB Time w(X) w(Y) • Nellapratica: le scritturesulla base di dati • possonoavvenire in qualsiasimomentoa • patto di garantire le due regole sui log ..

GestionedelleTransazioni • I guastipossonoesseredovuti a: • Malfunzionamentisoftware perdita del contenutodellamemoriaprincipale, nessundanno per la memoriasecondaria. • Malfunzionamentihardware (1)  perdita di datinellamemoriasecondaria, ma non nellamemoria stabile. • Malfunzionamentihardware (2)  perdita di datinellamemoriasecondaria e stabile.

Fail Stop Normal Fail Boot Restart completato Restart GestionedelleTransazioni • Modello di funzionamento (fail-stop) • Il DBMS usatrestati: • Normal esecuzionenormale • Stop occorrenza di un guasto • Restart ripristinodaiguasti

Fail Stop Normal Fail Boot Restart completato Restart GestionedelleTransazioni • Modello di funzionamento (fail-stop) • Due tipi di operazioni di ripristino: • Ripresa a caldo  Malfunziomentisoftware. • Ripresa a freddo Malfunzionamenti hardware (1).

GestionedelleTransazioni • La ripresa a caldosiarticola in 4 fasi: Si accede al log, lo siscorrefinoall’ultimo record di checkpoint. B(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3), C(T1), B(T4), U(T3,O2, B3, A3), U(T3,O3, B4, A4) CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6) D(T3,O5,B7), A(T3), C(T5), I(T2,O6,A8)

GestionedelleTransazioni • Si decidono le transazioni da annullare (undo) o da rifare (redo). • Si costruiscono due insiemi: UNDO e REDO. • UNDO e’ inizializzato con la listadelletransazioniattive, REDO e’ vuoto. • Si aggiungono ad UNDO tutte le transazioni T di cui esiste un record B(T). • Si spostano da UNDO a REDO tutte le transazioni di cui esiste un record C(T).

GestionedelleTransazioni Per il set di UNDO siripercorreil file di log, disfacendotutte le azionieffettuate da ognitransazione T contenutanel set, dallapiu’ recenteallamenorecente. Per il set di REDO  siapplicano le azioniaffettuate da ognitransazione T contenutanel set, dallamenorecenteallapiu’ recente.

GestionedelleTransazioni B(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3), C(T1), B(T4), U(T3,O2, B3, A3), U(T4,O3, B4, A4) CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6) D(T3,O5,B7), A(T3), C(T5), I(T2,O6,A8) Transazioniattiveall’ultimo CK: {T2, T3, T4}. CostruzionedegliinsiemiUNDO/REDO UNDO={T2,T3,T4}, REDO={} C(T4)  UNDO={T2,T3} REDO={T4} B(T5)  UNDO={T2,T3,T5} REDO={T4} C(T5)  UNDO={T2,T3} REDO={T4,T5}

GestionedelleTransazioni B(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3), C(T1), B(T4), U(T3,O2, B3, A3), U(T4,O3, B4, A4) CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6) D(T3,O5,B7), A(T3), C(T5), I(T2,O6,A8) UNDO delletransazioni{T2,T3}: I(T2,O6,A8)  DELETE O6 D(T3,O5,B7)  INSERT (O5=B7) U(T3,O3,B5,A5)  O3=B5 U(T3,O2,B3,A3)  O2=B3 U(T2,O1,B1,A1)  O1=B1

GestionedelleTransazioni B(T1) B(T2) U(T2,O1,B1,A1), I(T1,O2,A2), B(T3), C(T1), B(T4), U(T3,O2, B3, A3), U(T4,O3, B4,A4) CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6) D(T3,O5,B7), A(T3), C(T5), I(T2,O6,A8) REDO delletransazioni{T4,T5}: U(T4,O3,B4,A4)  O3=A4 U(T5,O4,B6,A6)  O4=B6

GestionedelleTransazioni • La ripresa a freddosiarticola in 4 fasi: Si copiaildumpnel DB attuale (cercando di sovrascrivere solo la parte deteriorata). Relativamentealla parte deteriorata, siscorreil log dal dump in poi finoall’ultimocheckpoint, e sieffettuanotutte le azionidellatransazioniconcluse con un commit. Si effettua la ripresa a caldo(con l’algoritmovisto prima).

Gestore di Interrogazioni e aggiornamenti Gestoredelle transazioni Gestoredellaconcorrenza Gestoredei metodid’accesso Gestoredella affidabilità Gestore del buffer Gestoredella memoriasecondaria Memoria secondaria GestionedelleTransazioni • Gestoredelleaffidabilita’  garantisceatomicita’ e persistenzadelletransazioni. • Gestoredellaconcorrenza garantiscel’isolamentodelletransazioni.

GestionedelleTransazioni In un DMBS, le transazionivengonoeseguite in concorrenzaper ragioni di efficienza / scalabilita’ … Tuttavia, l’esecuzioneconcorrentedetermina un insieme di problematichechedevonoesseregestite … T1= Read(x); x=x+1; Write(x); Commit Work T2= Read(x); x=x+1; Write(x); Commit Work Se x=3, al terminedelletransazioni x vale 5 (esecuzionesequenziale) … ma in esecuzioneconcorrente?

GestionedelleTransazioni Problema1: Perdita di Aggiornamento T2 scrive 4 T1 scrive 4

GestionedelleTransazioni Problema2: Letturasporca T2 legge 4!

GestionedelleTransazioni Problema3: Lettureinconsistenti T1 legge 3! T1 legge 4!

GestionedelleTransazioni Problema4: Aggiornamento Fantasma Vincolo: x+y+z deve essere = a 1000 Vincolo violato!!

GestionedelleTransazioni Date un insieme di transazioniT1,T2, Tn, di cui ciascunaformata da un certoinsieme di operazioni di scrittura (wi) e lettura (ri): Es. T1=r1(x) r1(y) r1(z) w1(y) … Si definisceschedule la sequenza di operazioni di lettura/scrittura di tutte le transazionicosi’ come eseguitesulla base di dati: r1(x) r2(y) r1(y) w4(y) w2(z) …

GestionedelleTransazioni Uno schedule Ssi dice seriale se le azioni di ciascunatransazioneappaiono in sequenza, senzaessereinframezzateda azioni di altretransazioni. S={T1, T2, … Tn} Schedule serialeottenibile se: Le transazionisonoeseguiteunoallavolta(scenario non realistico) Le transazionisonocompletamenteindipendentil’unadall’altra (improbabile)

Schedule Serializzabili Schedule Seriali Schedule GestionedelleTransazioni Uno schedule Ssi dice serializzabilese produce lo stessorisultato di un qualunque scheduler serialeS’dellestessetransazioni. CLASSI

GestionedelleTransazioni • Come implementareilcontrollodellaconcorrenza? • I DMBS commercialiusanoilmeccanismodeilock per potereffettuareunaqualsiasioperazioni di lettura/scritturasuunarisorsa (tabella o valore di unacella), e’ necessario aver precedentementeacquisitoilcontrollo (lock) sullarisorsastessa. • Lock in lettura(accessocondiviso) • Lock in scrittura(mutuaesclusione)

GestionedelleTransazioni • Su ogni lock possonoessere definite due operazioni: • Richiesta del lock in lettura/scrittura. • Rilascio del lock (unlock) acquisito in precedenza. STATO DELLA RISORSA AZIONE

GestionedelleTransazioni Lock Manager  componente del DBMS responsabile di gestirei lock allerisorse del DB, e di rispondereallerichiestedelletransazioni. Per ciascunoggettox del DBMS: State(x)  statodell’oggetto(libero/r_locked/w_locked) Active(x)  listatransazioniattivesull’oggetto Queued(x)  listatransazionibloccatesull’oggetto STRUTTURE DATI del LOCK MANAGER

Basi di Dati e Sistemi Informativi