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


  condivisionedeidaN  concorrenza

  qualitàdeidaN  integrità

  efficienza  caricamento,query,sort

  controllodell'accesso  privatezza

  robustezza

fuocosuintegrità,concorrenza,robustezza,efficienza

IlconceGoditransazione


TRANSAZIONE(transacNon):ComplessodiOPERAZIONItendenNaportareilDBdaunostatocorreGoadunaltrostatocorreGo.

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

•  Atomicità•  Consistenza•  Isolamento

•  Durata(persistenza)

Atomicità


ATOMICITÀ(atomicity)delletransazioni:leoperazioniprevistecosNtuisconountuGounico,devonopertantoessereeseguitenellalorointerezzaononessereeseguiteperniente.

SERIALIZZAZIONEDELLEOPERAZIONI:LeoperazionieventualmentesvolteinparallelodevonoportareilDBadunostatoequivalenteall'esecuzioneserialedellemedesimeoperazioni.

LatransazioneèquindiunaTRASFORMAZIONEATOMICAdallostatoinizialeaquellofinale.


UnaTRANSAZIONEcosNtuisceunBLOCCODIRECOVERY(riprisNno)cioè:uninsiemedioperazionidelimitatedaistruzionialfinedipermeGereleoperazioni:

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

REDO(rifare):selatransazionehaavutosuccessomalemodifichealDBnonsonostateresepermanenN,lemodifichevannoripetute.

Atomicità

Transazione"benformata"


BEGINTRANSACTIONcodiceconmanipolazionedeidaN

(leGureescriGure)COMMITWORK/ROLLBACKWORK

codiceprivodimanipolazionedidaN

ENDTRANSACTION

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


ComportamenNpossibili:commitwork:successoCOMMIT:finecorreGodellapartedimodificadellatransazione

("impegno"delDBMSatrasferireidaNmodificaNinmemoriapermanente)

S 1 S 3 S rS 0 S 2

COMMIT

Atomicità


IncasodiguastoilsistemadiRECOVERYèincaricatodiriportareilDataBaseadunostatocorreGoprecedentealguasto.

STATOCORRETTOèunostatodelDBchenonrifleGeicambiamenNdovuNatransazionidimodificachenonsonostateterminateconsuccesso.

CAUSEDIGUASTO:

1)guastoall'internodiunatransazione2)guastoall'internodelswdibase

3)guastosullamemoriasecondaria4)guastosulsistemahardware

Recovery


GUASTOALL'INTERNODIUNATRANSAZIONE

a)ABORT:unatransazionesiinterrompeperunerroresojwareequindiilDBMSneesegueilROLLBACK(“ritornoindietro”dellemodificheapportateaidaN)

b)ROLLBACKdiunatransazione:unatransazionepuòautonomamentechiedereilrollbacksescopreinconsistenzaneidaNolanonfanbilitàdelleoperazioni

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

Recovery


ComportamenNpossibili:commitwork:successoCOMMIT:finecorreGodellapartedimodificadellatransazione

("impegno"delDBMSatrasferireidaNmodificaNinmemoriapermanente)

S 1 S 3 S rS 0 S 2

COMMIT

Atomicità


ComportamenNpossibili:rollbackwork(suicidio)abortforzato(omicidio)

S 1 S 3 S rS 0 S 2

UNDO UNDO

guasto

Atomicità


ComportamenNpossibili:commitwork:successodellatransazionemaguastodopoilcommiteprimadellaconclusione

S 1 S 3 S rS 0 S 2

REDO

guasto

Atomicità


LatransazionerispeGaivincolidiintegrità,comeconseguenza:selostatoinizialeècorreGoanchelostatofinaleècorreGo

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

PersistenzaGlieffendiuncommitworkdureranno“persempre”(indipendentementedaiguasNdelsistema)

Consistenza


•  controllodiaffidabilita’:atomicità,persistenza

•  controllodiconcorrenza:isolamento•  controllodiesecuzione:consistenza

•  Controllodiaffidabilitàsuldatabaseserver•  gesNoneingresso‐uscita•  gesNonememorie

•  gesNonebuffer•  gesNonecommitwork/rollbackwork

•  gesNonegiornale

PergaranNreleproprietàacid


•  memoriacentrale:

nonèpersistente

•  memoriadimassa:

èpersistentemapuòdanneggiarsi

•  memoriastabile:

memoriacheanchesesidanneggianonperdeidaNenoninterrompeilservizio:DISKMIRRORINGeRAID

Persistenzadellememorie


Leinformazionivengonoparallelementeriportatesusistemididischidiversi.

DISKDRIVE2

DISK1 DISK2

BUS1

BUS2

CPU1

CPU2

UNITA’MULTIPROCESSORE

DISKDRIVE1

Replicazioneon‐line:mirroring


DATABASESERVER

DATABASE

BACKUP

DUMP

IlDBMSNenesempreunavecchiacopiadelDBsuunaltrodisposiNvo(nastroodisco)aggiornataperiodicamente(DUMP).

Replicazioneoff‐line:unitàdibackup


razionale:

•  usofrequentedeidaNgiànelbuffer•  scriGuradifferitadellabasedidaNonmizzandolescriGuresu

disco

discobufferdimemoria

centrale

i/o

GesNonedellamemoriacentrale


paginax

paginay

memoriacentrale

bufferpool

y

x

Perognitransazionec’èuncertonumerodipaginedisponibilinelbufferpool,ilnumerodipendedalnumeroditransazioniedallelororichieste.LepaginecontenenNmodifichedevonoessereriscriGe.

Usodellamemoriacentrale


aSTEAL‐ paginecondaNdirty,cioèmodificaNma ancorasenzacommit,soGraGeauna

transazioneanvaeriportatesudiscoNOSTEALbFORCE‐ paginescriGealcommit‐workNOFORCE

Normalmente:NO‐STEAL,NO‐FORCE

Letransazionirilascianolepagineallafine,quellemodificateverrannoriscriGeinmemoriapermanente.SenecessariolepaginedelletransazionivengonorimpiazzateconlapoliNcaLRU(LeastRecentlyUsed).

PoliNchedigesNonedelbuffer


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)


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


PerilLOG(checonNenel'insiemediinformazioninecessarieesufficienNperriportareilDBinunostatocorreGo)siuNlizzaunprotocollodiNpoWAP(WriteAheadProtocol):

SiscriveunrecorddiBEGINsulLOGprimadiiniziarel'esecuzionediunatransazioneLemodificheeffeGuatevengonoregistratesuldiscodelLOG(chiamatoancheaudittrail)PRIMAdivenireesteseallamemoriasecondaria

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

Giornale


T1,T2eT3sonoOK.PerT4eT5ilsistemadeveriportareidaNallostatocorreGoanteriorealloroinizio.

ESEMPIO

METODIPERLAGESTIONEDELLETRANSAZIONI


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

a)fareononfareUNDOdipendedallapoliNcadigesNonedellemodifiche.

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


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

StatovecchiodeidaN

LOG

DO(WAP) Stato

nuovodeidaN

t1 t3

t2t1<t2<t3

Statovecchio

LOG

UNDOStatonuovo

PoliNcadiundo(gesNonedellemodifiche)


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

StatovecchiodeidaN

LOG

DO StatonuovodeidaN

t1

t3t2

t1<t2<t3

PoliNcadiundo(gesNonedellemodifiche)

PoliNcadicommit(gesNonedelbuffer)


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

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

StatoincertodeidaN

LOG

REDOStatonuovodeidaN

t1 t3

t2

PoliNchedirecovery


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

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

forzailgestoredelbufferascaricarelepagineperterminarelatransazione,• nonpermeGeunsollecitorilasciodeilock.


NOUNDO/REDOnonrichiedebeforeimage,• favorisceicasidifallimenNdelletransazioni.

NOUNDO/NOREDO• NOREDO:tuGelemodifichedevonoesserenelDBprimachelatransazionesiaconsiderataterminata.

• NOUNDO:nessunamodificadeveessereportatasulDBprimachelatransazionesiaconsiderataterminata.• PerciòunaoperazioneatomicadevetrasferireidaNe

registrareilCommit.

Siusalatecnicadellepagineombra(SHADOWPAGES)cheèmoltovelocemarichiedemoltamemoria

PoliNchedirecovery


po pn

pagetable

p.nuovep.ombra

doppiopuntatoredell’applicazioneallapagetable

po pnpo pn

commit undo

SHADOWPAGES

(operazioneatomica)

INCERTEZZADELRECOVERYNELCASODISYSTEMCRASH


Metododel“CHECKPOINT”nellapoliNcaUNDO/REDO

IncasodisystemcrashilcontenutodellamemoriaprincipaleedegliI/Obuffersèperduto.

CHECKPOINT


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?


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


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


checkpoint

T1èok,perT2eT4sifaREDO,perT3eT5UNDO

CHECKPOINT

Funzionamentodelrecoverymanager


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

2  Preparaduefile:UNDOLISTcongliidenNficatoridelletransazionianve,REDOLISTvuoto.


3  LeggeilLOGpartendodall'ulNmocheckpoint:setrovaBeginTransacNonregistralatransazionesullaUNDOLIST,setrovaCommitlaportanellaREDOLIST.

  AlterminelaUNDOLISTconNenelalistadelletransazionidaDISFARE,laREDOLISTquelladelletransazionidarifare.

4  IlLOGvienerielaboratoall'indietropercompieregliUNDOconivecchivalori

5  IlLOGvienerielaboratoinavanNperrifare(REDO)letransazionidarifare.

  NessunutenteèanvoduranteilRESTART.

Funzionamentodelrecoverymanager

Checkpoint


Almomentodelguastoedopo:

topdelgiornale

checkpoint

redolist

undolist

Incasodiguastodisistema


aguastosoj:perditainmemoriacentralee

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

bguastoharddanneggiamentodellamemoriadiscoe RIPRESAAFREDDO

Ripresaafreddo


• siriprisNnanoidaNaparNredall’ulNmobackup

• sieseguonoleoperazioniregistratesullogfinoall'istantedelguasto;persicurezzasiNeneillogsuundiscodiversodaquellodeidaN(spessoilogsono2).

• siesegueunaripresaacaldo

AltretecnichediRECOVERY


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


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


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.

E5 Transaz

Documents

Transcript of E5 Transaz