CMSC 424 – Database designLecture 23RecoveryMihai PopAdmin•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)RecoveryContext•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 solutionsReasons 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 dataApproach, 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 possibleSTEAL 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 implicationsForceNo ForceNo StealStealDesiredTrivialSTEAL 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 undosLog-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 = 200Log•Example transactions T0 and T1 (T0 executes before T1):T0: read (A) T1 : read (C)A: - A - 50 C:- C- 100write (A) write (C)read (B)B:- B + 50write (B)•Log:Log-based Recovery■Assumptions:Log records are immediately pushed to the disk as soon as they are generatedLog records are written to disk in the order generatedA log record is generated before the actual data value is updatedStrict two-phase lockingThe first assumption can be relaxedAs 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 sequentialThey are also typically on a different disk■Aside: LFS == log-structured file systemLog-based Recovery■Assumptions:Log records are immediately pushed to the disk as soon as they are generatedLog records are written to disk in the order generatedA log record is generated before the actual data value is updatedStrict two-phase lockingThe first assumption can be relaxedAs 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 diskThis 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 diskUsing 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
View Full Document
Unlocking...