1 / 20

Recovery from “Bad” User Transactions

Recovery from “Bad” User Transactions. David Lomet, Zografoula Vagena, Roger Barga Microsoft Research Redmond, WA 98052. What is a “Bad” Transaction?. Transactions provide ACID properties A : atomicity C : consistency I : isolation D : Durability Database systems build in only AID

lynna
Télécharger la présentation

Recovery from “Bad” User Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Recovery from “Bad” User Transactions David Lomet, Zografoula Vagena, Roger Barga Microsoft ResearchRedmond, WA 98052

  2. What is a “Bad” Transaction? • Transactions provide ACID properties • A: atomicity • C: consistency • I: isolation • D: Durability • Database systems build in only AID • C: (consistency)is mostly responsibility of application • But user transaction can be “bad”!! • Wrong amount debited for a check or deposit • Order posted with wrong price for goods, etc. Dagstuhl, 3/21/06

  3. How do DBMS’s Cope Now? • Backup/Restore • Databases take backups for media failure • If disk page is corrupted • Backup is “restored”– used to replace the current data • Takes a long time • Recovery is run to bring the data up to current time • Using media recovery log (longer than crash recovery) • “Point in time” Recovery used for “bad” trans. • Use database backup – to restore data • Use media recovery log– but only roll forward to the “point in time” when bad transaction executed • De-commiting all following transactions • Manually re-submit and monitor re-execution of de-committed transactions • Takes a long time Very Costly Dagstuhl, 3/21/06

  4. Immortal DBA Transaction-time DB As of t2 As of t1 time At t1: RecA At t2: RecB RecC • Transaction-time DB: preserves all DB states as timestamped versions- supporting • “as of” query of DB: e.g. bank balances as of March • time travel: e.g. history of bank account over past year Dagstuhl, 3/21/06

  5. Immortal DB Technique “Point in time” backup must be “RESTORED” Version store “Point-in-time decommits all later transactions Our Backup is always “installed” Only transactions with “tainted” data are decommitted Un-impacted Transactions are preserved “Point in time” line: backup rolled forward via “recovery” Time Dagstuhl, 3/21/06

  6. Log T1: R(X0) W(X1:21) T2: R(W0,Y0) W(W2:12) T3: R(X1,Y0) W(X3:33) T4: R(X1,Y0) W(X3:33) T4: R(Y0,Z0) W(Y4:34) T5: R(X3, Z0) W(Z5:45) T6: R(W2,Z5) W(W6:16) Must cope with “Ripple Effects” of Bad User Transaction W X Y Z T0: X=20 T0: Y=30 T0: Z=40 T0: W=10 T1: X=21 T2: W=12 T3: X=33 T4: Y=34 T5: Z=45 T6: W=16 Time Dagstuhl, 3/21/06

  7. Our Method • Normal Run-Time Overhead • Log Reads: single log record (format in next slide) • Enables us to deal with “ripple effects”– we compute transitive closure • Bad Transaction is Detected • This is human activity • Tainted Versions are Identified • Find data of bad transaction • Transitive closure of reads/writes to find rest • Tainted Versions are Invalidated,i.e. logically removed • Marked as invalid via “version chain” processing • Dealing with invalid deletions is “vexing” • Problem: handling data that should be there but isn’t • Logically removed transactions may be re-submitted • This is a manual activity • Database is now ready for normal execution • Versions have been invalidated- invisible to normal execution • But they can continue to be seen by special operations • Heal database to restore performance (as needed) • Explained later Dagstuhl, 3/21/06

  8. HEADER TABLE SCANS LEFT OPEN RANGES Table ID RIGHT END KEY Variable Record Fields RIGHT OPEN RANGES CLOSED RANGES Table ID Table ID LEFT END KEY SINGLE RECORDS Table ID LEFT END KEY RIGHT END KEY Table ID RECORD KEY Log Record for Reads Normal Runtime OverheadLogging Reads Deals with phantoms Dagstuhl, 3/21/06

  9. Bad User Transaction Detected Dagstuhl, 3/21/06

  10. Identify Tainted Versions • Define “tainted data” table (in memory) • <record key, timestamp> entries where • Timestamp is earliest time of invalidation • All later versions with same record key are invalid • User identifies “bad transaction” by timestamp of its versions • Scan back in log to find “bad” transaction and all its updates • Enter these versions in “tainted data” table • Scan forward in log and check whether transaction has read tainted versions • If so, enter these versions in “tainted data” table unless already present • At end of log, all tainted versions have been identified and are in “tainted data” table Dagstuhl, 3/21/06

  11. Invalidate Tainted Versions • Versions with Keys in Tainted Table • Have start times of their “invalidity” • That appear in current DB • Follow version chains • Back to timestamp in Tainted Table • Marking as “invalid” records later than timestamp • See next slides • That do not appear in current DB • They have been deleted • By an unpropagated “invalid (tainted) delete stub” (IDS) • Search back via page chain, • despite absence of version in page Dagstuhl, 3/21/06

  12. At3 At2 At1 Bt1 Bt4 Linking Intra-Page Versions Page Header Slot 1 0 Dagstuhl, 3/21/06

  13. Linking Inter-Page Versions DeleteStub: Not Propagated Record Deletion Backpointer: page number and slot number Time of Split Time Dagstuhl, 3/21/06

  14. Log T1: R(X0) W(X1:21) T2: R(W0,Y0) W(W2:12) T3: R(X1,Y0) W(X3:33) T4: R(X1,Y0) W(X3:33) T4: R(Y0,Z0) W(Y4:34) T5: R(X3, Z0) W(Z5:45) T6: R(W2,Z5) W(W6:16) Logical Effect: Remove Tainted Data W X Y Z T0: X=20 T0: Y=30 T0: Z=40 T0: W=10 T2: W=12 T4: Y=34 Time Dagstuhl, 3/21/06

  15. After “Bad” Transaction Database Access • Marked versions are ignored in subsequent normal DB access • Follow version chain back to unmarked version • Tainted versions can be made visible to specially issued transactions • But what about versions that are not present • But would have been if not deleted by a tainted transaction? Dagstuhl, 3/21/06

  16. IDS Delete Stubs Complication! Current Page Historical Page UnPropagated Invalid Delete Stub: <Rec A, Ti> should be present Invalid Deletion From tainted transaction <Rec A, Ti> should be here!!! <Rec A, Ti> Page Backpointer: Time of Split Time Dagstuhl, 3/21/06

  17. Queries to IDS Pages • Point query: single key • Follow page chain back until • Valid version is found (return that version) OR • IDS flag no longer present (return “not found”) • Range query • Follow page chain back until • IDS flag is no longer present • Return all versions valid at AS OF time Dagstuhl, 3/21/06

  18. Healing IDS Pages • Important tohealpages to restore system performance • IDS flag dropped when page ishealed • Via Updating • New record with same key replacing unpropagated IDS • Via Key Split • One page might not have unpropagated IDS • Healing bookkeeping is a bit cumbersome Dagstuhl, 3/21/06

  19. Summary • Fast recovery from BAD user transactions • Exploiting Immortal DB historical versions • De-committing only tainted transaction data • Via logging of reads • Invalidating tainted versions • Making them logically invisible • Solving the unpropagated “invalid delete stub” problem • And healing the database Dagstuhl, 3/21/06

  20. Final Slide • Web site for Immortal DB • http://research.microsoft.com/research/db/immortaldb/ • Questions???? Dagstuhl, 3/21/06

More Related