e5 transaz

BasidiDa(‐Sistemitransazionali2

C)ModelloRelazionale,Algebrarelazionale,SQL

1 2 3 4 5 6 7

E)TecnologiadiunDBMS

1 2 3 4 5 6

A)Introduzione

1 2

B)Prog.ConceGuale(ER)

1 2 3 4 5 6 7

D)Prog.LogicaeNormalizzazione

1 2 3 4

F)ProgrammazioneDB

1 2

RicordiamoleprincipalicaraGerisNchedeiDBMS

BasidiDa(‐Sistemitransazionali3

  condivisionedeidaN  concorrenza

  qualitàdeidaN  integrità

  efficienza  caricamento,query,sort

  controllodell'accesso  privatezza

  robustezza

fuocosuintegrità,concorrenza,robustezza,efficienza

IlconceGoditransazione

BasidiDa(‐Sistemitransazionali4

TRANSAZIONE(transacNon):ComplessodiOPERAZIONItendenNaportareilDBdaunostatocorreGoadunaltrostatocorreGo.

Latransazioneèun’unitàdielaborazionechegodedi4proprietà(ACID):

•  Atomicità•  Consistenza•  Isolamento

•  Durata(persistenza)

Atomicità

BasidiDa(‐Sistemitransazionali5

ATOMICITÀ(atomicity)delletransazioni:leoperazioniprevistecosNtuisconountuGounico,devonopertantoessereeseguitenellalorointerezzaononessereeseguiteperniente.

SERIALIZZAZIONEDELLEOPERAZIONI:LeoperazionieventualmentesvolteinparallelodevonoportareilDBadunostatoequivalenteall'esecuzioneserialedellemedesimeoperazioni.

LatransazioneèquindiunaTRASFORMAZIONEATOMICAdallostatoinizialeaquellofinale.

BasidiDa(‐Sistemitransazionali6

UnaTRANSAZIONEcosNtuisceunBLOCCODIRECOVERY(riprisNno)cioè:uninsiemedioperazionidelimitatedaistruzionialfinedipermeGereleoperazioni:

UNDO(disfare):incasodifallimentodellatransazionedeveesserepossibile"disfare"l'azionesvoltasuidaN

REDO(rifare):selatransazionehaavutosuccessomalemodifichealDBnonsonostateresepermanenN,lemodifichevannoripetute.

Atomicità

Transazione"benformata"

BasidiDa(‐Sistemitransazionali7

BEGINTRANSACTIONcodiceconmanipolazionedeidaN

(leGureescriGure)COMMITWORK/ROLLBACKWORK

codiceprivodimanipolazionedidaN

ENDTRANSACTION

S 1 S 3 S fS i S 2W1 W2 W3 W4

BasidiDa(‐Sistemitransazionali8

ComportamenNpossibili:commitwork:successoCOMMIT:finecorreGodellapartedimodificadellatransazione

("impegno"delDBMSatrasferireidaNmodificaNinmemoriapermanente)

S 1 S 3 S rS 0 S 2

COMMIT

Atomicità

BasidiDa(‐Sistemitransazionali9

IncasodiguastoilsistemadiRECOVERYèincaricatodiriportareilDataBaseadunostatocorreGoprecedentealguasto.

STATOCORRETTOèunostatodelDBchenonrifleGeicambiamenNdovuNatransazionidimodificachenonsonostateterminateconsuccesso.

CAUSEDIGUASTO:

1)guastoall'internodiunatransazione2)guastoall'internodelswdibase

3)guastosullamemoriasecondaria4)guastosulsistemahardware

Recovery

BasidiDa(‐Sistemitransazionali10

GUASTOALL'INTERNODIUNATRANSAZIONE

a)ABORT:unatransazionesiinterrompeperunerroresojwareequindiilDBMSneesegueilROLLBACK(“ritornoindietro”dellemodificheapportateaidaN)

b)ROLLBACKdiunatransazione:unatransazionepuòautonomamentechiedereilrollbacksescopreinconsistenzaneidaNolanonfanbilitàdelleoperazioni

c)ABORTFORZATOdiunatransazione:unatransazione“aborNta”èforzataalrollbackseilDBMSscopreviolazionedivincoliodiautorizzazioni,situazionidistallo(deadlock),fallimentodialtretransazionicoordinateinparallelo.

Recovery

BasidiDa(‐Sistemitransazionali11

ComportamenNpossibili:commitwork:successoCOMMIT:finecorreGodellapartedimodificadellatransazione

("impegno"delDBMSatrasferireidaNmodificaNinmemoriapermanente)

S 1 S 3 S rS 0 S 2

COMMIT

Atomicità

BasidiDa(‐Sistemitransazionali12

ComportamenNpossibili:rollbackwork(suicidio)abortforzato(omicidio)

S 1 S 3 S rS 0 S 2

UNDO UNDO

guasto

Atomicità

BasidiDa(‐Sistemitransazionali13

ComportamenNpossibili:commitwork:successodellatransazionemaguastodopoilcommiteprimadellaconclusione

S 1 S 3 S rS 0 S 2

REDO

guasto

Atomicità

BasidiDa(‐Sistemitransazionali14

LatransazionerispeGaivincolidiintegrità,comeconseguenza:selostatoinizialeècorreGoanchelostatofinaleècorreGo

IsolamentoLatransazioneèisolatadallealtretransazioniconcorrenN(nonesponeisuoistaNintermediprimadellasuaconclusione).Sievital'“effeGodomino”

PersistenzaGlieffendiuncommitworkdureranno“persempre”(indipendentementedaiguasNdelsistema)

Consistenza

BasidiDa(‐Sistemitransazionali15

•  controllodiaffidabilita’:atomicità,persistenza

•  controllodiconcorrenza:isolamento•  controllodiesecuzione:consistenza

•  Controllodiaffidabilitàsuldatabaseserver•  gesNoneingresso‐uscita•  gesNonememorie

•  gesNonebuffer•  gesNonecommitwork/rollbackwork

•  gesNonegiornale

PergaranNreleproprietàacid

BasidiDa(‐Sistemitransazionali16

•  memoriacentrale:

nonèpersistente

•  memoriadimassa:

èpersistentemapuòdanneggiarsi

•  memoriastabile:

memoriacheanchesesidanneggianonperdeidaNenoninterrompeilservizio:DISKMIRRORINGeRAID

Persistenzadellememorie

BasidiDa(‐Sistemitransazionali17

Leinformazionivengonoparallelementeriportatesusistemididischidiversi.

DISKDRIVE2

DISK1 DISK2

BUS1

BUS2

CPU1

CPU2

UNITA’MULTIPROCESSORE

DISKDRIVE1

Replicazioneon‐line:mirroring

BasidiDa(‐Sistemitransazionali18

DATABASESERVER

DATABASE

BACKUP

DUMP

IlDBMSNenesempreunavecchiacopiadelDBsuunaltrodisposiNvo(nastroodisco)aggiornataperiodicamente(DUMP).

Replicazioneoff‐line:unitàdibackup

BasidiDa(‐Sistemitransazionali19

razionale:

•  usofrequentedeidaNgiànelbuffer•  scriGuradifferitadellabasedidaNonmizzandolescriGuresu

disco

discobufferdimemoria

centrale

i/o

GesNonedellamemoriacentrale

BasidiDa(‐Sistemitransazionali20

paginax

paginay

memoriacentrale

bufferpool

y

x

Perognitransazionec’èuncertonumerodipaginedisponibilinelbufferpool,ilnumerodipendedalnumeroditransazioniedallelororichieste.LepaginecontenenNmodifichedevonoessereriscriGe.

Usodellamemoriacentrale

BasidiDa(‐Sistemitransazionali21

aSTEAL‐ paginecondaNdirty,cioèmodificaNma ancorasenzacommit,soGraGeauna

transazioneanvaeriportatesudiscoNOSTEALbFORCE‐ paginescriGealcommit‐workNOFORCE

Normalmente:NO‐STEAL,NO‐FORCE

Letransazionirilascianolepagineallafine,quellemodificateverrannoriscriGeinmemoriapermanente.SenecessariolepaginedelletransazionivengonorimpiazzateconlapoliNcaLRU(LeastRecentlyUsed).

PoliNchedigesNonedelbuffer

BasidiDa(‐Sistemitransazionali22

IlLOGregistrainmemoriastabileleazionisvoltedallatransazionesoGoformadicoppiedivalori:

UPDATE(U)trasforma:val1⇒val2

registrazione:BEFORE‐STATE(U)=val1AFTER‐STATE(U)=val2(chiamateanchebefore/ajerimage)

TIPIDIREGISTRAZIONINELGIORNALE:1BEGIN‐TRANSACTION2UPDATE/DELETE/INSERT3COMMIT/ABORT4  CHECKPOINT

Giornaleditransazione(Logfile)

BasidiDa(‐Sistemitransazionali23

B(T1) U(T1) U(T1) C(T1)

topdelgiornalerecorddellatransazioniT1

LeinformazioniregistratesonodelNpo:1)idenNficatoredellatransazione;2)codicedioperazione;3)numerodisequenzanellog;4)puntatoreall'ulNmologrecorddellatransazione;5)idenNficatoredelfileedindirizzodelrecord(Nd);6)vecchiovalore,nuovovalore;

Ilgiornaleèsequenziale

BasidiDa(‐Sistemitransazionali24

PerilLOG(checonNenel'insiemediinformazioninecessarieesufficienNperriportareilDBinunostatocorreGo)siuNlizzaunprotocollodiNpoWAP(WriteAheadProtocol):

SiscriveunrecorddiBEGINsulLOGprimadiiniziarel'esecuzionediunatransazioneLemodificheeffeGuatevengonoregistratesuldiscodelLOG(chiamatoancheaudittrail)PRIMAdivenireesteseallamemoriasecondaria

IlLOGèpresenteintuniDBMSdiunacertaimportanza.Insistemicheeseguonomoltetransazionipuòoccupareunospaziomoltoelevato(LOGdicenNnaiadimilionidicaraGerialgiornoinsistemicommerciali)..

Giornale

BasidiDa(‐Sistemitransazionali25

T1,T2eT3sonoOK.PerT4eT5ilsistemadeveriportareidaNallostatocorreGoanteriorealloroinizio.

ESEMPIO

METODIPERLAGESTIONEDELLETRANSAZIONI

BasidiDa(‐Sistemitransazionali26

1)UNDO/REDO2)UNDO/NOREDO3)NOUNDO/REDO4)NOUNDO/NOREDO

a)fareononfareUNDOdipendedallapoliNcadigesNonedellemodifiche.

b)fareononfareREDOdipendedallagesNonedelBUFFERedelCOMMIT.IlREDOvafaGoperchéanchesesiraggiungeilCOMMITsulLOG,nonsièsicurichelepaginesianostatetuGescaricaNdalbuffer.

BasidiDa(‐Sistemitransazionali27

POLITICAa1FASE:(UNDO)lemodifichevengonoportatesubitosulDBdurantelosvolgimentodellatransazione,primadellaterminazione(STEAL).

StatovecchiodeidaN

LOG

DO(WAP) Stato

nuovodeidaN

t1 t3

t2t1<t2<t3

Statovecchio

LOG

UNDOStatonuovo

PoliNcadiundo(gesNonedellemodifiche)

BasidiDa(‐Sistemitransazionali28

POLITICAa2FASI:(NOUNDO)tuGelemodifichesonoregistratesulLOGtemporaneamenteenonsulDB;soloselatransazioneterminacorreGamentealloravengonoportatesulDBstabile(conunaoperazioneatomica)(NOSTEAL).

StatovecchiodeidaN

LOG

DO StatonuovodeidaN

t1

t3t2

t1<t2<t3

PoliNcadiundo(gesNonedellemodifiche)

PoliNcadicommit(gesNonedelbuffer)

BasidiDa(‐Sistemitransazionali29

COMMITposNcipato:(NOREDO)ilcommitèdefiniNvosolodopochelemodifichesonomigratesulDB(primalemodifiche,poiilcommitsullog)(FORCE)

COMMITanNcipato:(REDO)ilcommitèregistratosubitosulLOGprimachelemodifichesianocompletatesulDB(NOFORCE).

StatoincertodeidaN

LOG

REDOStatonuovodeidaN

t1 t3

t2

PoliNchedirecovery

BasidiDa(‐Sistemitransazionali30

UNDO/REDOrichiedebeforeandajerimage,• lascialagesNonedellepaginealgestoredelbufferchepuòonmizzareiltrasferimentosudisco,• migliorailfunzionamentonormale,• peggiorailfunzionamentosiaincasodiguasNdisistemaalRESTARTchediguasNditransazioni,• permeGeunpiùsollecitorilasciodeilock.

UNDO/NOREDOrichiedeajerimage,• migliorailcasodiRESTART,• peggiorailcasodiguastoditransazione,• peggiorailfunzionamentonormaledelbufferpoiché

forzailgestoredelbufferascaricarelepagineperterminarelatransazione,• nonpermeGeunsollecitorilasciodeilock.

BasidiDa(‐Sistemitransazionali31

NOUNDO/REDOnonrichiedebeforeimage,• favorisceicasidifallimenNdelletransazioni.

NOUNDO/NOREDO• NOREDO:tuGelemodifichedevonoesserenelDBprimachelatransazionesiaconsiderataterminata.

• NOUNDO:nessunamodificadeveessereportatasulDBprimachelatransazionesiaconsiderataterminata.• PerciòunaoperazioneatomicadevetrasferireidaNe

registrareilCommit.

Siusalatecnicadellepagineombra(SHADOWPAGES)cheèmoltovelocemarichiedemoltamemoria

PoliNchedirecovery

BasidiDa(‐Sistemitransazionali32

po pn

pagetable

p.nuovep.ombra

doppiopuntatoredell’applicazioneallapagetable

po pnpo pn

commit undo

SHADOWPAGES

(operazioneatomica)

INCERTEZZADELRECOVERYNELCASODISYSTEMCRASH

BasidiDa(‐Sistemitransazionali33

Metododel“CHECKPOINT”nellapoliNcaUNDO/REDO

IncasodisystemcrashilcontenutodellamemoriaprincipaleedegliI/Obuffersèperduto.

CHECKPOINT

BasidiDa(‐Sistemitransazionali34

T3 e T5 sicuramente non sono state completate e devonoesseresoGoposteallaproceduradiUNDO.

Per T1, T2 e T4, che sono terminate, non è sicuro se gliaggiornamenNsonostaNdefiniNvamentecopiaNsumemoriaausiliaria.

Bisogna quindi controllare sul LOG e se queste hannoraggiuntoilCOMMIT(commitrecordnelLog)bisognafarneilREDO.

Quanto indietronel LOGbisognaandare,peressere sicuridieseguire il recoverydituGeletransazioniterminate inmodocorreGo?

BasidiDa(‐Sistemitransazionali35

CHECKPOINTSYSTEMPeriodicamenteilsistemaesegueilcheckdelDB:

metodo1fa terminare le transazioni non ancora terminate e ricopiatuGoilcontenutodelbufferdimemoriacentraledesNnatoalDBsuldiscoedinserisceun"checkpointrecord"nelLOG.

Il sistemaDBMS,dopo il restartdel sistemadi calcolo, cercanelLOGl'ulNmocheckpointrecordedeseguelasuaproceduradi RECOVERY sulle transazioni iniziate dopo. Se il guastoavviene durante l’operazione di checkpoint è valido ilcheckpointprecedente.

CHECKPOINT

BasidiDa(‐Sistemitransazionali36

CHECKPOINTSYSTEMPeriodicamenteilsistemaesegueilcheckdelDB:

metodo2ricopia tuGe le pagine di transazioni terminate sul disco edinserisce un "checkpoint record" nel LOG, registra nelcheckpoint record gli idenNficatori delle transazioni nonancoraterminate.

Il sistemaDBMS,dopo il restartdel sistemadi calcolo, cercanelLOGl'ulNmocheckpointrecordedeseguelasuaproceduradi RECOVERY sulle transazioni iniziate dopo e su quelleregistratenelcheckpointrecord.

CHECKPOINT

BasidiDa(‐Sistemitransazionali37

checkpoint

T1èok,perT2eT4sifaREDO,perT3eT5UNDO

CHECKPOINT

Funzionamentodelrecoverymanager

BasidiDa(‐Sistemitransazionali38

  Ilrecoverymanager,alrestartdelsistema,esegueunprotocollodelNpo:1  LeggesuunfilediRESTART(semprecontenutonelLOG)l'indirizzodell'ulNmoCHECKPOINT;nelrecorddicheckpointsonocontenuNgliidenNficatoridelletransazionianvealmomentodelcheckpoint.

2  Preparaduefile:UNDOLISTcongliidenNficatoridelletransazionianve,REDOLISTvuoto.

BasidiDa(‐Sistemitransazionali39

3  LeggeilLOGpartendodall'ulNmocheckpoint:setrovaBeginTransacNonregistralatransazionesullaUNDOLIST,setrovaCommitlaportanellaREDOLIST.

  AlterminelaUNDOLISTconNenelalistadelletransazionidaDISFARE,laREDOLISTquelladelletransazionidarifare.

4  IlLOGvienerielaboratoall'indietropercompieregliUNDOconivecchivalori

5  IlLOGvienerielaboratoinavanNperrifare(REDO)letransazionidarifare.

  NessunutenteèanvoduranteilRESTART.

Funzionamentodelrecoverymanager

Checkpoint

BasidiDa(‐Sistemitransazionali40

Almomentodelguastoedopo:

topdelgiornale

checkpoint

redolist

undolist

Incasodiguastodisistema

BasidiDa(‐Sistemitransazionali41

aguastosoj:perditainmemoriacentralee

RIPRESA(RESTART)ACALDOproceduradirecoveryundo/redo comegiàvistooaltresimilineicasi noundo/redoecc.

bguastoharddanneggiamentodellamemoriadiscoe RIPRESAAFREDDO

Ripresaafreddo

BasidiDa(‐Sistemitransazionali42

• siriprisNnanoidaNaparNredall’ulNmobackup

• sieseguonoleoperazioniregistratesullogfinoall'istantedelguasto;persicurezzasiNeneillogsuundiscodiversodaquellodeidaN(spessoilogsono2).

• siesegueunaripresaacaldo

AltretecnichediRECOVERY

BasidiDa(‐Sistemitransazionali43

COPIEMULTIPLE: SimanNeneunnumerodisparidi copiedelDB. In casodiguasto, facendodei confronN fra levariecopie, inbaseadunprotocollodimaggioranzasionenelacopiacorreGa.Duranteunamodifica,unadellecopievieneuNlizzataperscrivereinuovivalori.UnflagvieneseGatoperindicareun"updateinprogress"ancheperlealtrecopie.Successivamentelamodificavieneestesainparallelo(perquantopossibile)atuGelealtrecopie.EssequindisonosemprecorreGe(eduguali),esclusigliistanNincuisieseguelascriGura.TecnicamoltouNlizzatanelleapplicazioniavanzate(spaziali,militari,etc....).

FORWARDERRORRECOVERY

BasidiDa(‐Sistemitransazionali44

1)BACKWARDERRORRECOVERY: è quella già vista che stabilisce che il riprisNno del DBavvengaritornandoadunostatopassatocorreGo.(Senonèpossibile, si cerca di riportare il DB in uno stato almenoconsistente).SonoletecnicheusatedaiDBMSperisistemiaziendali.

2)FORWARDERRORRECOVERY: tecnicacheproseguenormalmentel'esecuzione(sepossibile)tentandounacompensazionedeglierrori.NonpermeGel'usoditecnichegeneralimasolodialgoritmispecifici.Usatainsistemistrategicioincasiincuinonc’ètempoperilrecoverybackward.

AltretecnichediRECOVERY

BasidiDa(‐Sistemitransazionali45

HWCRASH:

SISTEMI RESILIENTI: sistemi completamente duplicaN chesvolgonoesaGamentelostessolavoro:ilsistema"slave"sosNtuisceimmediatamenteil"master"incasodiroGura.

In sistemi strategici i soGosistemi sono più di due: puòsussistereilproblema(grave)cheilmasternonlavoripiùinmodocorreGoeconsideriguasNglislavechealorovoltaloconsideranoguasto.Gli algoritmiper la gesNonediquestasituazionisonomoltocomplessi.

BasidiDa(‐Sistemitransazionali46