• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
2011 Db Transactions
 

2011 Db Transactions

on

  • 401 views

 

Statistics

Views

Total Views
401
Views on SlideShare
401
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

2011 Db Transactions 2011 Db Transactions Presentation Transcript

  • Transactions Alan Medlar amedlar@cs.ucl.ac.uk
  • Transactions • A transaction is a unit of work that is treated in a coherent and reliable manner. All transactions must be independent of one another
  • Transactions • A transaction is a unit of work that is treated in a coherent and reliable manner. All transactions must be independent of one another • Provide concurrency support (next lecture!)
  • Transactions • A transaction is a unit of work that is treated in a coherent and reliable manner. All transactions must be independent of one another • Provide concurrency support (next lecture!) • Fundamental in computer science
  • Properties • Handy mnemonic: ACID • Atomicity • Consistency • Integrity • Durability
  • Atomicity • Strong guarantee that changes to a database are applied “all or nothing”
  • Atomicity • Strong guarantee that changes to a database are applied “all or nothing” • Atomicity must be maintained in the face of failures (even from OS, hardware etc...)
  • Atomicity • Strong guarantee that changes to a database are applied “all or nothing” • Atomicity must be maintained in the face of failures (even from OS, hardware etc...) • E.g.: move £100 from my bank account to your bank account. If transfer to your account fails, I must be credited back!
  • Consistency • Transactions should not violate integrity constraints leaving database in illegal state • E.g.: age cannot be negative number
  • Isolation • Transactions should not affect one another
  • Isolation • Transactions should not affect one another • More precisely it defines when the changes resulting from a transaction will be seen by other concurrent transactions
  • Durability • Outcome of transaction must persist beyond its completion • i.e.: given a system crash, the state of the database can be recovered
  • Transaction Example • Debit £100 from Alice’s bank account and credit it to Bob’s account read(Alice) Alice = Alice - 100 write(Alice) read(Bob) Bob = Bob + 100 write(Bob)
  • Transaction Example • Debit £100 from Alice’s bank account and credit it to Bob’s account } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 write(Alice) read(Bob) Bob = Bob + 100 write(Bob)
  • Transaction Example • Debit £100 from Alice’s bank account and credit it to Bob’s account } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 write(Bob)
  • Transaction Example • Debit £100 from Alice’s bank account and credit it to Bob’s account } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 } £1950 Alice’s balance = £1900 write(Bob) Bob’s balance = £50
  • Transaction Example (2) • What if Bob’s account does not exist? Or permissions are set wrong?
  • Transaction Example (2) • What if Bob’s account does not exist? Or permissions are set wrong? read(Alice) Alice = Alice - 100 write(Alice) read(Bob) Bob = Bob + 100 write(Bob)
  • Transaction Example (2) • What if Bob’s account does not exist? Or permissions are set wrong? } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 write(Alice) read(Bob) Bob = Bob + 100 write(Bob)
  • Transaction Example (2) • What if Bob’s account does not exist? Or permissions are set wrong? } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 write(Bob)
  • Transaction Example (2) • What if Bob’s account does not exist? Or permissions are set wrong? } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 Read fails, must credit Alice back! write(Bob)
  • Atomicity } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 } £1950 Alice’s balance = £1900 write(Bob) Bob’s balance = £50
  • Atomicity Both writes succeed or neither do! } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 } £1950 Alice’s balance = £1900 write(Bob) Bob’s balance = £50
  • Consistency } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 } £1950 Alice’s balance = £1900 write(Bob) Bob’s balance = £50
  • Consistency Consistent state (no created or missing money!) } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 } £1950 Alice’s balance = £1900 write(Bob) Bob’s balance = £50
  • Isolation } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 } £1950 Alice’s balance = £1900 write(Bob) Bob’s balance = £50
  • Isolation No other transactions see intermediate values } £1950 Alice’s balance = £2000 Bob’s balance = £-50 read(Alice) Alice = Alice - 100 } £1850 Alice’s balance = £1900 write(Alice) Bob’s balance = £-50 read(Bob) Bob = Bob + 100 } £1950 Alice’s balance = £1900 write(Bob) Bob’s balance = £50
  • Durability • Transaction logs used to ensure durability
  • Durability • Transaction logs used to ensure durability • Log transaction writes, then update database
  • Durability • Transaction logs used to ensure durability • Log transaction writes, then update database • Logs must be written first or else updates can be lost given a system crash!
  • Durability • Transaction logs used to ensure durability • Log transaction writes, then update database • Logs must be written first or else updates can be lost given a system crash! • Disks can still fail! (disk mirroring?)
  • Failures • Possible failures include: • System crash • Hardware malfunctions • Disk failure • Deadlocks • System errors: out of memory, program errors (see “man 2 write”) • etc...
  • State Machine Partial Commit- commit ted Active Failed Aborted
  • State Machine Partial Commit- commit ted Active Initial state Failed Aborted
  • State Machine Last statement processed Partial Commit- commit ted Active Failed Aborted
  • State Machine Partial Commit- commit ted Completion Active (database updated) Failed Aborted
  • State Machine Partial Commit- commit ted Active Failed Aborted Processing can no longer proceed
  • State Machine Partial Commit- commit ted Active Failed Aborted Transaction rolled back to prior state
  • Transaction Logging • Transaction start: <T , start> i • Transaction write: <T , X ,V ,V > i j 1 2 • Transaction commit: <T , commit> i
  • Transaction Logging Transaction ID • Transaction start: <T , start> i • Transaction write: <T , X ,V ,V > i j 1 2 • Transaction commit: <T , commit> i
  • Transaction Logging Transaction ID Data item ID • Transaction start: <T , start> i • Transaction write: <T , X ,V ,V > i j 1 2 • Transaction commit: <T , commit> i
  • Transaction Logging Transaction ID Data item ID • Transaction start: <T , start> i • Transaction write: <T , X ,V ,V > i j 1 2 • Transaction commit: <T , commit> i Data values before and after write
  • Transaction Logging Transaction, ‘T’ read(Alice) Alice = Alice - 100 write(Alice) read(Bob) Bob = Bob + 100 write(Bob)
  • Transaction Logging Transaction, ‘T’ <T, start> read(Alice) Alice = Alice - 100 <T, Alice, 2000, 1900> write(Alice) read(Bob) Bob = Bob + 100 write(Bob) <T, Bob, -50, 50> <T, commit>
  • Transaction Logging Transaction, ‘T’ <T, start> read(Alice) Alice = Alice - 100 <T, Alice, 2000, 1900> write(Alice) read(Bob) Bob = Bob + 100 write(Bob) <T, Bob, -50, 50> <T, commit>
  • Transaction Logging Transaction, ‘T’ <T, start> read(Alice) Alice = Alice - 100 <T, Alice, 2000, 1900> write(Alice) read(Bob) Bob = Bob + 100 write(Bob) <T, Bob, -50, 50> <T, commit>
  • Transaction Logging Transaction, ‘T’ <T, start> read(Alice) Alice = Alice - 100 <T, Alice, 2000, 1900> write(Alice) read(Bob) Bob = Bob + 100 write(Bob) <T, Bob, -50, 50> <T, commit>
  • Deferred Modification • Ensure atomicity by deferring all writes until partial commit of transaction • <T , commit> is a partial commit (only i affected log so far, not database) • Given logs are in stable storage, writes can be made to the database itself !
  • Failure Recovery • If the system fails we can use the transaction log to recover the database • For all <T , start>, <T , commit> in log redo i i writes sequentially
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example } <T1, start> start and commit <T1, Alice, 2000, 1900> present <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example <T1, start> Redo <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> Redo <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> } <T2, start> <T2, Alice, 1900, 1800> no commit! <T3, start>
  • Immediate Modification • Instead of waiting for a commit, we could just perform the writes as they happen (but still post-log writing) • Incomplete transactions written to database require old value V1
  • Failure Recovery • Again, if the system fails we use the transaction log to recover the database • For all <T , start>, <T , commit> in log redo i i database write • For all <T , start>, without <T , commit> in i i log undo write
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example <T1, start> Redo <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> Redo <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> Redo <T2, Alice, 1900, 1800> <T3, start>
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> No Commit! <T3, start>
  • Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> Undo <T2, Alice, 1900, 1800> <T3, start>
  • Check-points • Speed up recovery! • Create a “check-point” to reduce work to be done given a failure • Flush all buffers to disk • Write <checkpoint> to log • On failure: read log until <checkpoint> found, then start recovery
  • Next: Concurrent Transactions