Your SlideShare is downloading. ×
2011 Db Transactions
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

2011 Db Transactions

217
views

Published on

Published in: Travel, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
217
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
































































  • Transcript

    • 1. Transactions Alan Medlar amedlar@cs.ucl.ac.uk
    • 2. 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
    • 3. 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!)
    • 4. 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
    • 5. Properties • Handy mnemonic: ACID • Atomicity • Consistency • Integrity • Durability
    • 6. Atomicity • Strong guarantee that changes to a database are applied “all or nothing”
    • 7. 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...)
    • 8. 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!
    • 9. Consistency • Transactions should not violate integrity constraints leaving database in illegal state • E.g.: age cannot be negative number
    • 10. Isolation • Transactions should not affect one another
    • 11. 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
    • 12. Durability • Outcome of transaction must persist beyond its completion • i.e.: given a system crash, the state of the database can be recovered
    • 13. 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)
    • 14. 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)
    • 15. 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)
    • 16. 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
    • 17. Transaction Example (2) • What if Bob’s account does not exist? Or permissions are set wrong?
    • 18. 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)
    • 19. 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)
    • 20. 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)
    • 21. 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)
    • 22. 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
    • 23. 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
    • 24. 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
    • 25. 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
    • 26. 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
    • 27. 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
    • 28. Durability • Transaction logs used to ensure durability
    • 29. Durability • Transaction logs used to ensure durability • Log transaction writes, then update database
    • 30. 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!
    • 31. 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?)
    • 32. Failures • Possible failures include: • System crash • Hardware malfunctions • Disk failure • Deadlocks • System errors: out of memory, program errors (see “man 2 write”) • etc...
    • 33. State Machine Partial Commit- commit ted Active Failed Aborted
    • 34. State Machine Partial Commit- commit ted Active Initial state Failed Aborted
    • 35. State Machine Last statement processed Partial Commit- commit ted Active Failed Aborted
    • 36. State Machine Partial Commit- commit ted Completion Active (database updated) Failed Aborted
    • 37. State Machine Partial Commit- commit ted Active Failed Aborted Processing can no longer proceed
    • 38. State Machine Partial Commit- commit ted Active Failed Aborted Transaction rolled back to prior state
    • 39. Transaction Logging • Transaction start: <T , start> i • Transaction write: <T , X ,V ,V > i j 1 2 • Transaction commit: <T , commit> i
    • 40. Transaction Logging Transaction ID • Transaction start: <T , start> i • Transaction write: <T , X ,V ,V > i j 1 2 • Transaction commit: <T , commit> i
    • 41. 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
    • 42. 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
    • 43. Transaction Logging Transaction, ‘T’ read(Alice) Alice = Alice - 100 write(Alice) read(Bob) Bob = Bob + 100 write(Bob)
    • 44. 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>
    • 45. 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>
    • 46. 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>
    • 47. 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>
    • 48. 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 !
    • 49. 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
    • 50. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    • 51. 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>
    • 52. Recovery Example <T1, start> Redo <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    • 53. Recovery Example <T1, start> <T1, Alice, 2000, 1900> Redo <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    • 54. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> } <T2, start> <T2, Alice, 1900, 1800> no commit! <T3, start>
    • 55. 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
    • 56. 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
    • 57. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    • 58. Recovery Example <T1, start> Redo <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    • 59. Recovery Example <T1, start> <T1, Alice, 2000, 1900> Redo <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    • 60. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> Redo <T2, Alice, 1900, 1800> <T3, start>
    • 61. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> No Commit! <T3, start>
    • 62. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> Undo <T2, Alice, 1900, 1800> <T3, start>
    • 63. 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
    • 64. Next: Concurrent Transactions