2011 Db Transactions

413 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
413
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
































































  • 2011 Db Transactions

    1. 1. Transactions Alan Medlar amedlar@cs.ucl.ac.uk
    2. 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. 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. 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. 5. Properties • Handy mnemonic: ACID • Atomicity • Consistency • Integrity • Durability
    6. 6. Atomicity • Strong guarantee that changes to a database are applied “all or nothing”
    7. 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. 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. 9. Consistency • Transactions should not violate integrity constraints leaving database in illegal state • E.g.: age cannot be negative number
    10. 10. Isolation • Transactions should not affect one another
    11. 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. 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. 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. 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. 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. 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. 17. Transaction Example (2) • What if Bob’s account does not exist? Or permissions are set wrong?
    18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28. Durability • Transaction logs used to ensure durability
    29. 29. Durability • Transaction logs used to ensure durability • Log transaction writes, then update database
    30. 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. 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. 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. 33. State Machine Partial Commit- commit ted Active Failed Aborted
    34. 34. State Machine Partial Commit- commit ted Active Initial state Failed Aborted
    35. 35. State Machine Last statement processed Partial Commit- commit ted Active Failed Aborted
    36. 36. State Machine Partial Commit- commit ted Completion Active (database updated) Failed Aborted
    37. 37. State Machine Partial Commit- commit ted Active Failed Aborted Processing can no longer proceed
    38. 38. State Machine Partial Commit- commit ted Active Failed Aborted Transaction rolled back to prior state
    39. 39. Transaction Logging • Transaction start: <T , start> i • Transaction write: <T , X ,V ,V > i j 1 2 • Transaction commit: <T , commit> i
    40. 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. 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. 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. 43. Transaction Logging Transaction, ‘T’ read(Alice) Alice = Alice - 100 write(Alice) read(Bob) Bob = Bob + 100 write(Bob)
    44. 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. 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. 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. 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. 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. 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. 50. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    51. 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. 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. 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. 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. 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. 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. 57. Recovery Example <T1, start> <T1, Alice, 2000, 1900> <T1, Bob, -50, 50> <T1, commit> <T2, start> <T2, Alice, 1900, 1800> <T3, start>
    58. 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. 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. 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. 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. 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. 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. 64. Next: Concurrent Transactions

    ×