CompSci516 Data Intensive Computing Systems · 2016. 12. 18. · • REDO • UNDO/REDO • ARIES – an UNDO/REDO log implementation Duke CS, Fall 2016 CompSci 516: Data Intensive
Post on 24-Aug-2021
2 Views
Preview:
Transcript
CompSci 516DataIntensiveComputingSystems
Lecture13-14Transactions–
Recovery
Instructor:Sudeepa Roy
1DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Announcements• HW2dueonMonday10/17• Midtermprojectreportdueon10/28
– projecthassame20%weightasthemidterm!• SeeclarificationsonLecture12onpiazza
2DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
ReadingMaterial• [GUW]
– Chapter17.2.1-17.2.4(UNDO)– Chapter17.3.1-17.3.4(REDO– nextlecture)– Lectureslideswillbesufficientforexams
3
Acknowledgement:Afewofthefollowingslideshavebeencreatedadaptingtheinstructormaterialofthe[RG]bookprovidedbytheauthorsDr.RamakrishnanandDr.Gehrke.
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
LastLecture• DynamicDatabase+PhantomProblem• Multiple-granularitylocks• Alternativestimestamp-based(notlock-based)approachestoCC– Optimistic:validationtests– Timestamp:RT(O)&WT(O)oneachobjectO– Multiversion:multipleversionsofeachobjectOwithdifferentWTandRT
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 4
Today
Recovery• STEAL/NOSTEAL• FORCE/NOFORCE• UNDOlog• REDOlog
– tobecontinuedinthenext1-2lecture
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 5
TransactionRecoveryandLogs
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 6
Review:TheACIDproperties
• A tomicity: Allactionsinthetransactionhappen,ornonehappen.
• C onsistency: Ifeachtransactionisconsistent,andtheDBstartsconsistent,itendsupconsistent.
• I solation: Executionofonetransactionisisolatedfromthatofothertransactions.
• Durability: Ifatransactioncommits,itseffectspersist.
• WhichpropertydidwecoverinCC?
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 7
Review:TheACIDproperties
• A tomicity: Allactionsinthetransactionhappen,ornonehappen.
• C onsistency: Ifeachtransactionisconsistent,andtheDBstartsconsistent,itendsupconsistent.
• I solation: Executionofonetransactionisisolatedfromthatofothertransactions.
• Durability: Ifatransactioncommits,itseffectspersist.
• WhichpropertydidwecoverinCC?:Isolation
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 8
Review:TheACIDproperties
• A tomicity: Allactionsinthetransactionhappen,ornonehappen.
• C onsistency: Ifeachtransactionisconsistent,andtheDBstartsconsistent,itendsupconsistent.
• I solation: Executionofonetransactionisisolatedfromthatofothertransactions.
• Durability: Ifatransactioncommits,itseffectspersist.
• Next:TheRecoveryManagerguaranteesAtomicity&Durability.• RecallthatConsistencyisprogrammer’sresponsibility
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 9
Motivation:A&D• Atomicity:
– Transactionsmayabort(“Rollback”).
• Durability:– WhatifDBMSstopsrunning?(powerfailure/crash/error/fire-
floodetc.)
crash!❖ Desired Behavior after system restarts:
– T1, T2 & T3 should be durable.– T4 & T5 should be aborted (effects
not seen).T1T2T3T4T5
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 10
Recovery:A&D
• Atomicity– by”undo”ing actionsof“abortedtransactions”
• Durability– bymakingsurethatallactionsofcommittedtransactionssurvivecrashesandsystemfailure
– i.e.by“redo”-ing actionsof“committedtransactions”
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 11
DBArchitectureforTransactions
• Tr.mgr.issuessignals– tologmgr.tostorelogrecords– tobuffermgr.aboutwhenitshouldcopybuffertodisk– toqueryprocessortoexecutequeries/operationsthatcompromisethetransaction
• Logmgr.– maintainslog,dealswithbuffermgr.sincefirstlogappearsinbuffertheniswrittentodisk
• Recoverymgr.– Ifthereisacrash,itisactivated– examinesthelogandrepairsdataifnecessary
• Note:accesstothediskisthroughthebuffermgr.DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 12
Data
Log
Buffermanager
Recoverymanager
QueryProcessor
Transactionmanager Logmanager
Assumptions
• Concurrencycontrolisineffect
• Updatesarehappening“inplace”.– i.e.dataisoverwrittenon(deletedfrom)thedisk.
• SimpleschemestoguaranteeAtomicity&Durability(next):– NOSTEAL– FORCE
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 13
HandlingtheBufferPool• Force everywritetodisk?– Poorresponsetime– Butprovidesdurability
• Steal buffer-poolframesfromuncommittedtransactions?– Ifnot,poorthroughput– Ifso,howcanweensureatomicity?
Force
No Force
No Steal Steal
Trivial
Desired
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 14
MoreonStealandForce• STEAL (whyenforcingAtomicityishard)
– TostealframeF:CurrentpageinF(sayP)iswrittentodisk;sometransactionholdslockonP
• Whatifthetransaction withthelockonPaborts?• MustremembertheoldvalueofPatstealtime(tosupportUNDOing thewritetopageP)
• NOFORCE(whyenforcingDurabilityishard)– Whatifsystemcrashesbeforeamodifiedpageiswrittentodisk?
– Writeaslittleaspossible,inaconvenientplace,atcommittime,tosupportREDOing modifications.
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 15
BasicIdea:Logging• RecordREDOandUNDOinformation,foreveryupdate,inalog– Sequentialwritestolog(putitonaseparatedisk)
– Minimalinfo(diff)writtentolog,somultipleupdatesfitinasinglelogpage
• Log:AnorderedlistofREDO/UNDOactions– Logrecordmaycontain:
<Tr.ID,pageID,offset,length,olddata,newdata>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 16
Differenttypesoflogs
• UNDO• REDO• UNDO/REDO
• ARIES– anUNDO/REDOlogimplementation
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 17
GUW17.2,17.3,17.4(LecturematerialwillbesufficientforHWsandExams)
Nextlecture,[RG]18,andaresearchpaper
Recall:LogRecords
• Afileopenedforappendingonly
• Logblocksarecreatedandupdatedinthemainmemoryfirst– thenwrittentodisk
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 18
UNDOlogging
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 19
UNDOlogging
• Makerepairtothedatabasebyundoing theeffectoftransactionsthathavenotfinished– i.e.uncommittedtransactionsbeforeacrashorabortedtransactions
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 20
TypesofUNDOlogrecords• <STARTT>: transactionThasbegun• <COMMITT>:Thascompletedsuccessfully,nomorechangeswill
bemade– Notethatseeing<COMMITT>doesnotautomaticallyensurethatchanges
havebeenwrittentodisk,hastobeenforcedbylogmanager
• <ABORTT>:transactionTcouldnotcompletesuccessfully– jobofthetransactionmgr toensurethatchangesbyTneverappearondisk
orarecancelled
• <T,X,v>:updaterecordforUNDOlog– ThaschangedobjectX,anditsformervaluewasv– ThischangenormallyhappenedinmemoryafteraWRITE,notafter
OUTPUTtodisk– NOTE:weonlyrecordtheoldvalue,notthenewvalue– sinceUNDOlog,whileundoing,replacewitholdvalueDukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 21
UNDOloggingrules
1. (U1)IfTmodifiesX,thenlogrecord<T,X,v>mustbewrittentodiskbefore thenewvalueofXiswrittentodisk
2. (U2)IfTcommits,<COMMITT>mustbewrittentodisk afteralldatabaseelementschangedbyTarewrittentodisk
– butassoonthereafteraspossible
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 22
OrderofwritetodiskforUNDOlog
• Summarizingtworules:1. First,thelogrecordsindicatingchangedDB
elements shouldbewritten
2. Second,thechangedvaluesoftheDBelementsshouldbewritten
3. Finally,theCOMMITlogrecordshouldbewritten
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 23
foreachelement,notasagroup
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
24
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
25
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
26
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
27
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
28
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
29
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
WRITE(B,t) 16 16 16 8 8 <T,B,8>
30
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
WRITE(B,t) 16 16 16 8 8 <T,B,8>
FLUSH LOG
31
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
WRITE(B,t) 16 16 16 8 8 <T,B,8>
FLUSH LOG
OUTPUT(A) 16 16 16 16 8
32
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
WRITE(B,t) 16 16 16 8 8 <T,B,8>
FLUSH LOG
OUTPUT(A) 16 16 16 16 8
OUTPUT(B) 16 16 16 16 16
33
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
WRITE(B,t) 16 16 16 8 8 <T,B,8>
FLUSH LOG
OUTPUT(A) 16 16 16 16 8
OUTPUT(B) 16 16 16 16 16
<COMMIT T>
34
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
8 8 <START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
WRITE(B,t) 16 16 16 8 8 <T,B,8>
FLUSH LOG
OUTPUT(A) 16 16 16 16 8
OUTPUT(B) 16 16 16 16 16
<COMMIT T>
FLUSH LOG
35
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log
<START T>
READ(A,t) 8 8 8 8
t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>
READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8
WRITE(B,t) 16 16 16 8 8 <T,B,8>
FLUSH LOG
OUTPUT(A) 16 16 16 16 8
OUTPUT(B) 16 16 16 16 16
<COMMIT T>
FLUSH LOG
36
initiallyA=8,B=8 EXAMPLE:UNDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
RecoveryusingUNDOlogging
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 37
• firstsimple (lookatentirelog)• then“checkpointing”(noneedtolookatentirelog)
RecoverywithUNDOlog• Scanfromtheend
• If<COMMITT>isfoundinlog– allchangesbyThavebeenwrittentodisk– OK
• <STARTT>foundbutno<COMMITT>– somechangesmightbewritten,somenot– ChangesbyTondiskhavetobeUNDONE
• Recallrule1:– “IfTmodifiesX,thenlogrecord<T,X,v>mustbewrittentodiskbefore
thenewvalueofXiswrittentodisk”– vwasprevious valueofX– Foreachsuchchangeondisk,therewillbealogrecordondiskaswell– ResetvalueofXtovinrecovery
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 38
UNDO:orderofwritingtodisk1. <STARTT>2. <T,A,10>(oldvalue10)3. A=12(newvalue12)4. <COMMITT>
RecoverywithUNDOlog• Travelbackward
– scanthelogfromtheendtowardthestart• Rememberwhetheryouhaveseen<COMMITT>or<ABORTT>forallT
• Suppose<T,X,v>isencountered
1. If<COMMITT>hasbeenseen,donothing– nothingtoundo,newvaluealreadywritten
2. Otherwise,a) Tisincompleteorabortedb) ChangethevalueofXtov
3. If<ABORTT>notfounda) write<ABORTT>b) flushthelogc) resumenormaloperation
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 39
UNDO:orderofwritingtodisk1. <STARTT>2. <T,A,10>(oldvalue10)3. A=12(newvalue12)4. <COMMITT>
Action T Mem A Mem B Disk A Disk B Log<START T>
READ(A,t) 8 8 8 8t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8WRITE(B,t) 16 16 16 8 8 <T,B,8>FLUSH LOGOUTPUT(A) 16 16 16 16 8OUTPUT(B) 16 16 16 16 16
<COMMIT T>FLUSH LOG
40
initiallyA=8,B=8
• Crashafter finalflush• <COMMITT>alreadyondisks• AlllogrecordsbyTareignoredbytherecoverymanager
Crashexample1
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
EXAMPLE:UNDOLOG
Action T Mem A Mem B Disk A Disk B Log<START T>
READ(A,t) 8 8 8 8t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8WRITE(B,t) 16 16 16 8 8 <T,B,8>FLUSH LOGOUTPUT(A) 16 16 16 16 8OUTPUT(B) 16 16 16 16 16
<COMMIT T>FLUSH LOG
41
initiallyA=8,B=8
• Crashbefore finalflush• <COMMITT>notondisk• Gobackward,first<T,B,8>found,setB=8ondisk
Crashexample2,Step1
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
EXAMPLE:UNDOLOG
Action T Mem A Mem B Disk A Disk B Log<START T>
READ(A,t) 8 8 8 8t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8WRITE(B,t) 16 16 16 8 8 <T,B,8>FLUSH LOGOUTPUT(A) 16 16 16 16 8OUTPUT(B) 16 16 16 16 16
<COMMIT T>FLUSH LOG
42
initiallyA=8,B=8
• Crashbefore finalflush• <COMMITT>notondisk• Gobackward,first<T,B,8>found,setB=8ondisk• Then<T,A,8>isfound,setA=8ondisk
Crashexample2,Step2
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
EXAMPLE:UNDOLOG
Action T Mem A Mem B Disk A Disk B Log<START T>
READ(A,t) 8 8 8 8t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8WRITE(B,t) 16 16 16 8 8 <T,B,8>FLUSH LOGOUTPUT(A) 16 16 16 16 8OUTPUT(B) 16 16 16 16 16
<COMMIT T>FLUSH LOG
43
initiallyA=8,B=8
• Crashbefore finalflush• <COMMITT>notondisk• Gobackward,first<T,B,8>found,setB=8ondisk• Then<T,A,8>isfound,setA=8ondisk• <STARTT>found.NothingelsecanbefoundinthelogforT.Write<ABORTT>
Crashexample2,Step3
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
EXAMPLE:UNDOLOG
Action T Mem A Mem B Disk A Disk B Log<START T>
READ(A,t) 8 8 8 8t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8WRITE(B,t) 16 16 16 8 8 <T,B,8>FLUSH LOGOUTPUT(A) 16 16 16 16 8OUTPUT(B) 16 16 16 16 16
<COMMIT T>FLUSH LOG
44
initiallyA=8,B=8
• Crashbefore FIRSTflush• <T,A,8>,<T,B,8>,<COMMITT>notondisk• ByruleU1,AandBnotchangedondisk- donothing
Crashexample3
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
EXAMPLE:UNDOLOG
Action T Mem A Mem B Disk A Disk B Log<START T>
READ(A,t) 8 8 8 8t:=t*2 16 8 8 8
WRITE(A,t) 16 16 8 8 <T,A,8>READ(B,t) 8 16 8 8 8
t:=t*2 16 16 8 8 8WRITE(B,t) 16 16 16 8 8 <T,B,8>FLUSH LOGOUTPUT(A) 16 16 16 16 8OUTPUT(B) 16 16 16 16 16
<COMMIT T>FLUSH LOG
45
initiallyA=8,B=8
• Crashbefore FIRSTflush• <T,A,8>,<T,B,8>,<COMMITT>notondisk• ByruleU1,AandBnotchangedondisk- donothing
Crashexample3
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
EXAMPLE:UNDOLOG
DoesthisUNDOmethodworkifTchangesAtwice?A=16A=24?
Checkpointing forUNDOlog
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 46
Checkpointing Motivation• Sofar,recoveryrequireseverylogrecordtobeexamined
• Ifwehaveseen<COMMITT>,noneedtoexaminelogrecordsofT– allchangesalreadyondisk
• Still,wemaynotbeabletotruncatelogafteronetransactioncommitted– logrecordsofotheractivetransactionsmightbelost– alwaysneedtoscanuntilthestartofthelog
• Explicitlycheckpointthelogperiodically– Wecanstopscanningthelogaftercertainpoints
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 47
Checkpointing process
1. Stopacceptingnewtransactions2. Waituntilallcurrentlyactivetransactionscommitorabort,
andhavewritten<COMMIT>or<ABORT>logrecord3. Flushlogtodisk4. Writeacheckpointing logrecord<CKPT>,flushthelogagain5. Resumeacceptingtransactions
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 48
RecoveryusingCheckpointingforUNDOlog
Logrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<T2,B,10>
<T2,C,15>
<T1,D,20>
<COMMIT T1>
<COMMITT2>
<CKPT>
<STARTT3>
<T3,E,25>
<T3,F,30>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 49
• Donotacceptnewtransaction• FinishT1,T2
– theycommitted
• Thenwrite<CKPT>onlog• Thencanacceptnewtransaction
– HereT3
suppose,wanttockpt here
RecoveryusingCheckpointingforUNDOlog
Logrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<T2,B,10>
<T2,C,15>
<T1,D,20>
<COMMIT T1>
<COMMITT2>
<CKPT>
<STARTT3>
<T3,E,25>
<T3,F,30>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 50
CRASH
• T3istheonlyincompletetransaction– RestoreFto30– RestoreEto25– inbackwarddirection
• Whenwereach<CKPT>,weknowthatnoneedtoexaminepriorlogrecords
• Restorationofthedatabaseiscomplete– CKPTistheearliest(last)logrecordreadbythe
recoverymanager
• Drawback:notransactioncanbeaccepteduntilalltheactiveonescommitandCKPTcompletes
suppose,wanttockpt here
Nonquiescent Checkpointing
• Avoidsstallingthesystemandcontinuesacceptingnewtransactions– “quiescent”=inastateorperiodofinactivityordormancy
1. Write<STARTCKPT(T1,…,Tk)>andflushthelog– T1,…Tk areactivetransactions(havenotcommittedandhavenot
writtentheirchangestodisk)
2. Checkpointing continuesuntilallofT1,..Tk abortsorcommits– butdonotprohibitothernewtransactionstostart
3. WhenallofT1,…,Tk havecompleted,write<ENDCKPT>andflushthelogagain
DukeCS,Fall2016 CompSci 516:DataIntensiveComputingSystems 51
Example:Nonquiescent CheckpointingforUNDOlogLogrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<T2,B,10>
<STARTCKPT(T1,T2)>
<T2,C,15>
<STARTT3>
<T1,D,20>
<COMMIT T1>
<T3, E,25>
<COMMITT2>
<ENDCKPT>
<T3,F,30>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 52
• <STARTCKPT(T1,T2)>– sinceT1,T2areonlyactivetransactionsat
thatpoint– <ENDCKPT>afterbothcommitted
• <STARTT3>duringcheckpointing
RecoverywithNonquiescentCheckpointing forUNDOlog
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 53
• Scanlogfromtheend(asbefore)– findallincompletetransactionaswego– restorevaluesforthosetransactions(undo)
• If<ENDCKPT>ismetfirst– allincompletetransactionsstartedafter<STARTCKPT….>– scanuntilthat<STARTCKPT…>- canstopatthatpoint– candeletelogrecordspriorto<STARTCKPT..>once<END
CKPT>iswrittentodisk
• If<STARTCKPT(T1,..,Tk)>ismetfirst– crashoccurredduringthecheckpoint– incompletetransactions=
• eitherstartedafter<STARTCKPT..> (HERET3)• oramongT1,…,Tk (HERET1,T2)
– Scanbackward– untiltheearliest<STARTtr>
ofallthesetransactionstr
UNDO:orderofwritingtodisk1. <STARTT>2. <T,A,10>(oldvalue10)3. A=12(newvalue12)4. <COMMITT>
Logrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<T2,B,10>
<STARTCKPT(T1,T2)>
<T2,C,15>
<STARTT3>
<T1,D,20>
<COMMIT T1>
<T3, E,25>
<COMMITT2>
<ENDCKPT>
<T3,F,30>
RecoverywithNonquiescentCheckpointing forUNDOlogLogrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<T2,B,10>
<STARTCKPT(T1,T2)>
<T2,C,15>
<STARTT3>
<T1,D,20>
<COMMIT T1>
<T3, E,25>
<COMMITT2>
<ENDCKPT>
<T3,F,30>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 54
CRASH
• First<T3,F,30>found– restoreFto30 (undochangebyT3)
• <ENDCKPT>found– Allincompletetransactionsstartedafter
corresponding<STARTCKPT..>
• <T3,E,25>found– restoreEto25 (undochangebyT3)
• Nootherrecordstorestoreuntil<STARTCKPT…>
• Stopthere– nofurtherchanges
RecoverywithNonquiescentCheckpointing forUNDOlogLogrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<T2,B,10>
<STARTCKPT(T1,T2)>
<T2,C,15>
<STARTT3>
<T1,D,20>
<COMMIT T1>
<T3, E,25>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 55
CRASH
• Scanbackward– no<ENDCKPT>found– but<STARTCKPT(T1,T2)>found– also<COMMITT1>found
• T3andT2incompletetransactions– T1alreadycommitted
• Scanuntiltheearliestof<STARTT2>and<STARTT3>– here<STARTT2>
• Alongthewaybackward– restoreEto25(undochangebyT3)– restoreCto15(undochangebyT2)– restoreBto10(undochangebyT2)– inthisorder– thenstopat<STARTT2>
ProblemswithUNDOlogging
• WecannotcommitTunlessallitschangesappearondisk
• SometimesdiskI/Os canbesavedifthechangescanstayinmainmemoryforawhile– aslongasthereisalogtofixthingsinacrash
• Idea:REDOlogging
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 56
UNDO:orderofwritingtodisk1. <STARTT>2. <T,A,10>(oldvalue10)3. A=12(newvalue12)4. <COMMITT>
ENDOFLECTURE13
REDOlogging
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 57
STARTOFLECTURE14
Review:UNDOLog
• STEAL– tobeabletostealmodifiedpagesbyarunningtransaction– mayhavetoUNDOforuncommittedtransactions
• NOFORCE– nottoforceeverywriteofrunningtransactiontodisk– mayhavetoREDOforcommittedtransactions
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 58
ConsideredbyUNDOlogUNDOuncommittedtransactionsIgnorecommittedtransactions
ConsideredbyREDOlogREDOcommittedtransactionsIgnoreuncommittedtransactions
Review:UNDOlogNon-quiescentcheckpointing• STARTCKPT<T1,T2,…>
– T1,T2,..areactive(noncommitted)transactions– flushlog
• Checkpointing runsuntiltheycommitorabort– canacceptnewtransactionstostart
• ENDCKPT– flushlogagain
• Recoverycheckswhether– ENDCKPTisfoundfirst(needtoreaduntilSTARTCKPT)– STARTCKPTisfoundfirst(mayhavetoreadbeyondSTARTCKPT)– UNDOuncommittedtransactions– seeexamplescoveredinLecture13
• Problem:wecannotcommitTuntilallwritesareondisk(slow)
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 59
UNDO:orderofwritingtodisk1. <STARTT>2. <T,A,10>(oldvalue10)3. A=12(newvalue12)4. <COMMITT>
UNDOvs.REDO
UNDO REDO
cancels(UNDO)theeffectofincompletetransactions
ignoresincompletetransactions
ignorescommittedones repeats(REDO)thechangesmadebycommittedones
requireswriting changedelementstodiskBEFORE thecommitlogrecordiswritten
requireswriting changedelementstodiskAFTERthecommitlogrecordiswritten
<T, X,v>:visOLD value ofX <T, Xv>:visNEW value ofX
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 60
TypesofREDOlogrecords• <STARTT>
– transactionThasbegun• <COMMITT>
– Thascompletedsuccessfully,nomorechangeswillbemade– Notethatseeing<COMMITT>doesnotautomaticallyensurethat
changeshavebeenwrittentodisk• hastobeenforcedbylogmanager
• <ABORTT>– transactionTcouldnotcompletesuccessfully– jobofthetransactionmgr toensurethatchangesbyTneverappear
ondiskorarecancelled
• <T,X,v>– updaterecordforREDOlog– ThaschangedobjectX,anditsNEWvalueisv
• NOTE:weonlyrecordthenew value,nottheoldvalue(unlikeUNDO)
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 61
sameasUNDO
REDOloggingrule
(R1)Before modifyinganyelementXondisk,alllogrecordspertainingtothismodification,including<T,X,v>and<COMMITT>,mustappearondisk
– single“redorule”– calledtheWRITE-AHEADLOGGING(WAL)rule
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 62
OrderofwritetodiskforREDOlog
1. First,thelogrecordsindicatingchangedDBelementsshouldbewritten
2. Second,TheCOMMITlogrecordshouldbewritten
3. Finally,thechangedDBelementsshouldbewritten
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 63
differentorderthanUNDOUNDO:orderofwritingtodisk
1. <STARTT>2. <T,A,10>(oldvalue10)3. A=12(newvalue12)4. <COMMITT>
REDO:orderofwritingtodisk1. <STARTT>2. <T,A,12>(newvalue12)3. <COMMITT>4. A=12(newvalue12)
Action T Mem A Mem B Disk A Disk B Log1 <START T>2 READ(A,t) 8 8 8 83 t:=t*2 16 8 8 84 WRITE(A,t) 16 16 8 8 <T, A, 16>5 READ(B,t) 8 16 8 8 86 t:=t*2 16 16 8 8 87 WRITE(B,t) 16 16 16 8 8 <T,B,16>8 <COMMIT T>9 FLUSH LOG10 OUTPUT(A) 16 16 16 16 811 OUTPUT(B) 16 16 16 16 16
64
initiallyA=8,B=8 EXAMPLE:REDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Action T Mem A Mem B Disk A Disk B Log1 <START T>2 READ(A,t) 8 8 8 83 t:=t*2 16 8 8 84 WRITE(A,t) 16 16 8 8 <T, A, 16>5 READ(B,t) 8 16 8 8 86 t:=t*2 16 16 8 8 87 WRITE(B,t) 16 16 16 8 8 <T, B,16>8 <COMMIT T>9 FLUSH LOG10 OUTPUT(A) 16 16 16 16 811 OUTPUT(B) 16 16 16 16 16
65
initiallyA=8,B=8 EXAMPLE:REDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
RecoveryusingREDOlogging
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 66
RecoverywithREDOlog• Identifycommittedtransactions
– scanfromtheendtoidentifycommittedtransactions– makeredochangesintheforwarddirection
• Foreachlogrecord<T,X,v>– IfTisnot acommittedtransaction
• donothing– IfTiscommitted
• writethevaluevofelementX
• ForeachincompletetransactionT– write<ABORTT>– Flushthelog
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 67
REDO:orderofwritingtodisk1. <STARTT>2. <T,A,12>(newvalue12)3. <COMMITT>4. A=12(newvalue12)
Action T Mem A Mem B Disk A Disk B Log1 <START T>2 READ(A,t) 8 8 8 83 t:=t*2 16 8 8 84 WRITE(A,t) 16 16 8 8 <T, A, 16>5 READ(B,t) 8 16 8 8 86 t:=t*2 16 16 8 8 87 WRITE(B,t) 16 16 16 8 8 <T,B,16>8 COMMIT <COMMIT T>9 FLUSH LOG10 OUTPUT(A) 16 16 16 16 811 OUTPUT(B) 16 16 16 16 16
68
initiallyA=8,B=8 EXAMPLE:REDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
• Crashafterstep9• <COMMITT>alreadyondisk– Tcommitted• <T,A,16>and<T,B,16>- writevaluesofA=16andB=16• Note:crashafterstep10or11----somewritesareredundantbutharmless
Crashexample1
Action T Mem A Mem B Disk A Disk B Log1 <START T>2 READ(A,t) 8 8 8 83 t:=t*2 16 8 8 84 WRITE(A,t) 16 16 8 8 <T, A, 16>5 READ(B,t) 8 16 8 8 86 t:=t*2 16 16 8 8 87 WRITE(B,t) 16 16 16 8 8 <T,B,16>8 COMMIT <COMMIT T>9 FLUSH LOG10 OUTPUT(A) 16 16 16 16 811 OUTPUT(B) 16 16 16 16 16
69
initiallyA=8,B=8 EXAMPLE:REDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
• Crashbeforestep9• <COMMITT>notondisk– Tnotcommitted– valuesnotupdatedondisk• NochangesofAandBondisk• Write<ABORTT>tolog
Crashexample2
Checkpointing forREDOlog
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 70
Checkpointing process
1. Writelogrecord<STARTCKPT(T1,…,Tk)>whereT1,…,Tk aretheactive(uncommitted)transactions,andflushthelog
2. Writetodiskalldb elementsthatwerewrittentobuffersbutnotyettodiskbytransactionsthathadalreadycommittedbeforethe<STARTCKPT>recordwaswrittentothelog
3. Writealogrecord<ENDCKPT>tothelogandflushthelog
Unlike(nonquiescent checkpointing for)UNDOlog,wecancompletethecheckpointing forREDOwithoutwaitingfortheactivetransactionstocommitorabort,astheyarenotwritingtodiskduringcheckpointing anyway
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 71
AREDOlogwithcheckpointingLogrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<COMMITT1>
<T2,B,10>
<STARTCKPT(T2)>
<T2,C,15>
<START T3>
<T3,D,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 72
• T2isongoing• OnlyT2in<STARTCKPT…>• Duringcheckpointing,writechanges
byT1todisk– alreadycommittedbeforethe
checkpointing started
• canacceptnewtransactionswhilecheckpointing (T3here)
Recovery:REDOlogwithcheckpointing
Logrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<COMMITT1>
<T2,B,10>
<STARTCKPT(T2)>
<T2,C,15>
<START T3>
<T3,D,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 73
• Findlastckpt <ENDCKPT>beforecrash
• everyvaluewrittenbycommittedtransactionsbefore<STARTCKPT…>alreadyondisk
– HereT1
• Limitrecovery(likebefore)onlyforcommittedtransactionsin<STARTCKPT…>orthosethatstartedafter<STARTCKPT…>– HereT2andT3– <COMMITT2>and<COMMITT3>foundafter
<STARTCKPT..>– bothtobeREdone
• Noneedtolookfurtherbackthantheearliestofthese<STARTTi>records– Here<STARTT2>
CRASH
Recovery:REDOlogwithcheckpointing
Logrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<COMMITT1>
<T2,B,10>
<STARTCKPT(T2)>
<T2,C,15>
<START T3>
<T3,D,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 74
• <COMMITT2>and<COMMITT3>foundafter<STARTCKPT..>– bothtobeREdone
• REDOUpdate(inorder)– <T2,B,10>:B=10– <T2,C,15>:C=15– <T3,D,20>:D=20
• Note:updatehastobeintheforwarddirection (redolog,unlikeundo)
CRASH
Recovery:REDOlogwithcheckpointing
Logrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<COMMITT1>
<T2,B,10>
<STARTCKPT(T2)>
<T2,C,15>
<START T3>
<T3,D,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 75
• Example1:
• Crashbefore<COMMITT3>
• T3hasnotcommitted
• Noneedtoredofor<T3,D,20>
Recovery:REDOlogwithcheckpointing
Logrecords
<STARTT1>
<T1,A,5>
<STARTT2>
<COMMITT1>
<T2,B,10>
<STARTCKPT(T2)>
<T2,C,15>
<START T3>
<T3,D,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 76
• Example2:
• Crashbefore<ENDCKPT>
• Needtofindlast<ENDCKPT>andthenits<STARTCKPT…>– Herenoother<ENDCKPT>– Scanuntilthestartofthelog
• Only<COMMITT1>found– RedoA=5for<T1,A,5>
ProsandConsUNDOvs.REDO
UNDO REDO
requiresdatatobewrittentodiskimmediatelyafteratransactionfinishes--mightincreasetheno.ofdiskI/Os that
needtobeperformed
requires ustokeepallmodifiedblocksinbuffersuntilthetransactioncommitsandthelogrecordshavebeenflushed– mightincreasetheaveragenumberofbuffers
requiredbytransactions
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 77
Alsobothmayhaveconflictsduringcheckpointing withsharedbuffers• supposeAinapageischangedbyacommittedtr butBischangedbya
uncommittedone• okifnosharedbuffers
Getbenefitsofboth– attheexpenseofmaintainingmorelogrecords
UNDO/REDOlogging
UNDO/REDOlogging
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 78
UNDO/REDOlogging
• <T,X,v,w>– TchangedthevalueofelementX– formervaluev– newvaluew
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 79
UNDO/REDOloggingrule
(URrule)Before modifyinganyelementXondisk,<T,X,v,w>mustappearondisk
– Onlyconstraintimposedbyboth UNDOandREDOlog– noconstrainton<COMMITT>
• canprecedeorfollowanyofthechangestothedb elementsondisk
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 80
UNDO:orderofwritingtodisk1. <STARTT>2. <T,A,10>(oldvalue10)3. A=12(newvalue12)4. <COMMITT>
REDO:orderofwritingtodisk1. <STARTT>2. <T,A,12>(newvalue12)3. <COMMITT>4. A=12(newvalue12)
Action T Mem A Mem B Disk A Disk B Log1 <START T>2 READ(A,t) 8 8 8 83 t:=t*2 16 8 8 84 WRITE(A,t) 16 16 8 8 <T, A, 8,16>5 READ(B,t) 8 16 8 8 86 t:=t*2 16 16 8 8 87 WRITE(B,t) 16 16 16 8 8 <T, B, 8,16>8 FLUSH LOG9 OUTPUT(A) 16 16 16 16 8
10 <COMMIT T>
11 OUTPUT(B) 16 16 16 16 16
81
initiallyA=8,B=8 EXAMPLE:UNDO/REDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Step10(commit)couldhavealsoappearedbeforeStep(8),beforeStep(9),orafterStep(11)
RecoveryusingUNDO/REDOlogging
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 82
RecoverywithUNDO/REDOlog• REDOallcommittedtransactionsintheorderearliest-first(forward)
• UNDOalluncommitted/incompletetransactionsintheorderlatestfirst(backward)
• Importanttodoboth– becauseoftheflexibilityallowedbyUNDO/REDOloggingregarding<COMMIT>records
• wecanhave– acommittedtransactionwithnotallchangeswrittentodisk
– anuncommittedtransactionswithsomechangeswrittentodisk
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 83
Action T Mem A Mem B Disk A Disk B Log1 <START T>2 READ(A,t) 8 8 8 83 t:=t*2 16 8 8 84 WRITE(A,t) 16 16 8 8 <T, A, 8,16>5 READ(B,t) 8 16 8 8 86 t:=t*2 16 16 8 8 87 WRITE(B,t) 16 16 16 8 8 <T, B, 8,16>8 FLUSH LOG9 OUTPUT(A) 16 16 16 16 8
10 <COMMIT T>
11 OUTPUT(B) 16 16 16 16 16
84
initiallyA=8,B=8 EXAMPLE:UNDO/REDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Crashexample1
• Crashafter <COMMITT>isflushedtodisk• Tisconsideredascommitted• FirstupdateAto16• ThenupdateBto16(forwarddirection)• Somechangesmaybeunnecessarybutharmless
Action T Mem A Mem B Disk A Disk B Log1 <START T>2 READ(A,t) 8 8 8 83 t:=t*2 16 8 8 84 WRITE(A,t) 16 16 8 8 <T, A, 8,16>5 READ(B,t) 8 16 8 8 86 t:=t*2 16 16 8 8 87 WRITE(B,t) 16 16 16 8 8 <T, B, 8,16>8 FLUSH LOG9 OUTPUT(A) 16 16 16 16 8
10 <COMMIT T>
11 OUTPUT(B) 16 16 16 16 16
85
initiallyA=8,B=8 EXAMPLE:UNDO/REDOLOG
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems
Crashexample1
• Crashbefore <COMMITT>isflushedtodisk• Tisconsideredasuncommitted• FirstupdateBto8• ThenupdateAto8(backwarddirection)• Somechangesmaybeunnecessarybutharmless
Checkpointing forUNDO/REDOlog
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 86
Checkpointing process
1. Writelogrecord<STARTCKPT(T1,…,Tk)>whereT1,…,Tk aretheactive(uncommitted)transactions,andflushthelog
2. Writetodiskall recordsthataredirty– i.e.containoneormorechangeddb elements– NOTE:unlikeREDOlogging,flushalldirtybuffers– notjustthose
writtenbycommittedtransactions
3. Writealogrecord<ENDCKPT>tothelogandflushthelog
Atransactionmustnotwriteanyvalue(eventomemorybuffers)untilitiscertainnottoabort
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 87
AnUNDO/REDOlogwithcheckpointingLogrecords
<STARTT1>
<T1,A,4,5>
<STARTT2>
<COMMITT1>
<T2,B,9,10>
<STARTCKPT(T2)>
<T2,C,14,15>
<START T3>
<T3,D,19,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 88
• T2isactive• T2’snewBvaluewillbewrittentodisk
whenthecheckpointing begins– unlikeREDO,wherefirstcommit,then
write
• DuringCKPT,– flushAtodiskifitisnotalreadythere
(dirtybuffer)• likeREDO
– flushBtodiskifitisnotalreadythere(dirtybuffer)
• unlikeREDO
Recovery:AnUNDO/REDOlogwithcheckpointing
Logrecords
<STARTT1>
<T1,A,4,5>
<STARTT2>
<COMMITT1>
<T2,B,9,10>
<STARTCKPT(T2)>
<T2,C,14,15>
<START T3>
<T3,D,19,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 89
• T1hascommittedandwritesondisk– ignoreT1
• REDOT2andT3• ForT2
– noneedtolookpriorto<STARTCKPT(T2)>– T2’schangesbeforeSTARTCKPTwere
flushedtodiskduringCKPT– unlikeREDO
CRASH
Recovery:AnUNDO/REDOlogwithcheckpointing
Logrecords
<STARTT1>
<T1,A,4,5>
<STARTT2>
<COMMITT1>
<T2,B,9,10>
<STARTCKPT(T2)>
<T2,C,14,15>
<START T3>
<T3,D,19,20>
<ENDCKPT>
<COMMITT2>
<COMMITT3>
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 90
• T1hascommittedandwritesondisk– ignoreT1
• T2committed,T3uncommitted• REDOT2andUNDOT3• ForT2
– setCto15– notnecessarytosetBto10(beforeEND
CKPT– alreadyondisk)• ForT3
– setDto19– ifT3hadstartedbeforeSTARTCKPT,would
havehadtolookbeforeSTARTCKPTformoreactionstobeundone
Summary• UNDOlogging
– <T,X,u>:uistheold valueofX– <T,X,u>todiskà X=newvaluetodiskà …<COMMITT>todisk– undouncommittedtransactions
• REDOlogging– <T,X,v>:visthenew valueofX– <T,X,v>todiskà ….<COMMITT>todiskà X=newvaluetodisk…– redocommittedtransactions
• UNDO/REDOlogging– <T,X,u,v>:uistheold valueofXandvisthenew valueofX– <T,X,u,v>todiskà X=newvaluetodisk– Noconstraintsonwriting<COMMITT>todisk– both:undouncommittedandredocommittedtransactions
• Understandforeachofthesethree– standardrecovery– checkpointing,and– recoverywithcheckpointing
DukeCS,Fall2016 CompSci516:DataIntensiveComputingSystems 91
top related