CMSC 424 Database design Lecture 23 Recovery Mihai Pop Admin Signup sheet for project presentations contact Sharath ASAP also check forum Course evaluation http www CourseEvalUM umd edu Additional queries deadline your demo day Find the authors their skills and education of the top 5 highest cited publications Find the most accomplished author in your database Use any ranking function for accomplishment e g of Papers of awards Recovery Context ACID properties We have talked about Isolation and Consistency How do we guarantee Atomicity and Durability Atomicity Two problems Part of the transaction is done but we want to cancel it ABORT ROLLBACK System crashes during the transaction Some changes made it to the disk some didn t Durability Transaction finished User notified But changes not sent to disk yet for performance reasons System crashed Essentially similar solutions Reasons for crashes Transaction failures Logical errors deadlocks System crash Power failures operating system bugs etc Disk failure Head crashes for now we will assume that either this does not happen or that RAID is used to handle this STABLE STORAGE Data never lost Can approximate by using RAID and maintaining geographically distant copies of the data Approach Assumptions etc Approach Guarantee A and D by controlling how the disk and memory interact by storing enough information during normal processing to recover from failures by developing algorithms to recover the database state Assumptions System may crash but the disk is durable The only atomicity guarantee is that a disk block write is atomic Once again obvious na ve solutions exist that work but that are too expensive E g The shadow copy solution we saw earlier Make a copy of the database do the changes on the copy do an atomic switch of the dbpointer at commit time Goal is to do this as efficiently as possible STEAL vs NO STEAL FORCE vs NO FORCE STEAL The buffer manager can steal a memory page from the database ie it can write an arbitrary page to the disk and use that page for something else from the disk In other words the database system doesn t control the buffer replacement policy Why a problem The page might contain dirty writes ie writes updates by a transaction that hasn t committed But we must allow steal for performance reasons NO STEAL Not allowed More control but less flexibility for the buffer manager STEAL vs NO STEAL FORCE vs NO FORCE FORCE The database system forces all the updates of a transaction to disk before committing Why To make its updates permanent before committing Why a problem Most probably random I Os so poor response time and throughput Interferes with the disk controlling policies NO FORCE Don t do the above Desired Problem Guaranteeing durability becomes hard We might still have to force some pages to disk but minimal STEAL vs NO STEAL FORCE vs NO FORCE Recovery implications No Force Force Desired Trivial No Steal Steal STEAL vs NO STEAL FORCE vs NO FORCE Recovery implications How to implement A and D when No Steal and Force Only updates from committed transaction are written to disk since no steal Updates from a transaction are forced to disk before commit since force A minor problem how do you guarantee that all updates from a transaction make it to the disk atomically Remember we are only guaranteed an atomic block write What if some updates make it to disk and other don t Can use something like shadow copying shadow paging No atomicity durability problem arise Terminology Deferred Database Modification write at commit time Similar to NO STEAL NO FORCE Not identical Only need redos no undos We won t cover this today Immediate Database Modification write anytime Similar to STEAL NO FORCE Need both redos and undos Log based Recovery Most commonly used recovery method Intuitively a log is a record of everything the database system does For every operation done by the database a log record is generated and stored typically on a different log disk T1 START T2 COMMIT T2 ABORT T1 A 100 200 T1 modified A old value 100 new value 200 Log Example transactions T0 and T1 T0 executes before T1 T0 read A A A 50 write A read B B B 50 write B Log T1 read C C C 100 write C Assumptions Log based Recovery Log records are immediately pushed to the disk as soon as they are generated Log records are written to disk in the order generated A log record is generated before the actual data value is updated Strict two phase locking The first assumption can be relaxed As a special case a transaction is considered committed only after the T1 COMMIT has been pushed to the disk But this seems like exactly what we are trying to avoid Log writes are sequential They are also typically on a different disk Aside LFS log structured file system Assumptions Log based Recovery Log records are immediately pushed to the disk as soon as they are generated Log records are written to disk in the order generated A log record is generated before the actual data value is updated Strict two phase locking The first assumption can be relaxed As a special case a transaction is considered committed only after the T1 COMMIT has been pushed to the disk NOTE As a result of assumptions 1 and 2 if data item A is updated the log record corresponding to the update is always forced to the disk before data item A is written to the disk This is actually the only property we need assumption 1 can be relaxed to just guarantee this called write ahead logging Using the log to abort rollback STEAL is allowed so changes of a transaction may have made it to the disk UNDO T1 Procedure executed to rollback undo the effects of a transaction E g T1 START T1 A 200 300 T1 B 400 300 T1 A 300 200 note second update of A T1 decides to abort Any of the changes might have made it to the disk Using the log to abort rollback UNDO T1 Go backwards in the log looking for log records belonging to T1 Restore the values to the old values NOTE Going backwards is important A was updated twice In the example we simply Restore A to 300 Restore B to 400 Restore A to 200 Note No other transaction better have changed A or B in the meantime Strict two phase locking Using the log to recover We don t require FORCE so a change made by the committed transaction may not have made it to the disk before the system crashed BUT the log record did recall our assumptions REDO T1 Procedure executed to recover a committed transaction E g T1 START T1 A 200 300 T1 B 400 300 T1 A 300 200 note second update of A T1 COMMIT By our
View Full Document
Unlocking...