1 / 22

Overview of DBMS recovery and concurrency control:

Overview of DBMS recovery and concurrency control:. Eksemplerne er fra kapitel 3 I bogen: Lars Fank Databaser Teori og Praksis ISBN 87-571-2397-7. Overview of DBMS recovery and concurrency control:. Recovery (Retablering ) Concurrency control (Samtidighedskontrol )

darci
Download Presentation

Overview of DBMS recovery and concurrency control:

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. Overview of DBMS recovery and concurrency control: Eksemplerne er fra kapitel 3 I bogen: Lars Fank Databaser Teori og Praksis ISBN 87-571-2397-7

  2. Overview of DBMS recovery and concurrency control: • Recovery (Retablering ) • Concurrency control (Samtidighedskontrol ) • Concurrency control versus availability (Samtidighedskontrol kontra stor tilgængelighed).

  3. Atomic transations:

  4. Why should a database transaction be atomic?

  5. The two-Phase-Commit (2PC) protocol: All updates must be executed in the first phase. That is before the commit. If the transaction fails in the first phase it must be aborted. If the transaction fails in the second phase the updates of the transaction must be stored in the database even though the updates may not have been transferred to the disc at the time of the commit. Why must all answers to the user about the result of the updates only be send in the second phase of 2PC? What should the user do if the user does not get an answer from the updating program?

  6. Layout of the DBMS log record: InsertDeleteUpdateBegin transactionCommit/Abort What is the operation code used for when the recovery program reads the log file for roll back recovery?

  7. Record types of the Log file: • Begin transaction. • Before and after images. • End transaction (commit or abort). • Database checkpoint with the identifications of all the non-committed transactions.

  8. Desired behavior after DBMS crash: T1 T2 T3 T4 T5 • Transactions T1, T2 & T3 should be durable. • T4 & T5should be aborted . crash! Checkpoint

  9. Restart by using DBMS checkpoint data: • Transactions T1, T2 & T3 should be durable. • T4 & T5should be aborted . T1 T2 T3 T4 T5 Checkpoint crash! Undo-queue. Undo-queue.Trans2 Trans4Trans4 Trans5 Redo-queue. Redo-queue. Trans2 Trans3

  10. How would you recommend to restart?

  11. The ACID properties of transactions: ----------------------------------------------- • Atomicity = the all or nothing update property. • Concistency = if a database is consistent before a transaction is execued, then the database must alo be consistent after the transaction is executed. • Isolation = The updates of a transaction must not be seen by other transactions before the transaction is committed. • Durability = Committed data can be log-recovered in case of failures (What is disasters recovery?).

  12. DBMS Implementation of ACID Properties: Logging and Recovery: Guarantees Atomicity and Durability. Concurrency control: Guarantees Consistency and Isolation.

  13. Overview of DBMS recovery and concurrency control: • Recovery (Retablering ) • Concurrency control (Samtidighedskontrol ) • Concurrency control versus availability (Samtidighedskontrol kontra stor tilgængelighed).

  14. Commit point shrinking phase Lock growing phase Two phase locking (2PL): All locks must be obtained in first phase of 2PL and released in second phase. Number of locks Time Is it the same phases that are used in 2PL and 2PC?

  15. Deadlock illustration Deadlock = Deadly embrace (dødelig omfavnelse) = A blocked situation where transactions mutually wait for the other transactions to unlock.

  16. Deadlock (Dødelig omfavnelse): • Suppose we have the following scenario: • T1 asks for an exclusive lock on record R1. • T2 asks for an exclusive lock on record R2. • T1 asks for a shared lock on record R2. • T2 asks for a shared lock on record R1.

  17. Deadlock detection by using a ”waits-for-graf”: In a waits-for-graf the nodes are active transactions and an arrow between two nodes signifies that a transaction waits for the unlock of another transaction. A deadloch has occurred when the graf has a cyclic loop.

  18. End of session Thank you !!!

  19. Deadlock Prevention • Give each transaction a timestamp. “Older” transactions have • higher priority. • Assume Ti requests a lock, but Tj holds a conflicting lock. • We can follow two strategies: • Wait-die: if Ti has higher priority, it waits; else Ti aborts. • Wound-wait: if Ti has higher priority, abort Tj; else Ti waits. • Note: after aborting, restart with original timestamp! Both strategies guarantee deadlock-free behavior!

  20. An Alternative to Prevention • In theory, deadlock can involve many transactions: • T1 waits-for T2 waits-for T3 ...waits-for T1 • In practice, most “deadlock cycles” involve only 2 • transactions. • Don’t need to prevent deadlock! • What’s the problem with prevention? • Allow it to happen, then notice it and fix it. • Deadlock detection.

  21. Deadlock Detection • Lock Manager maintains a “Waits-for” graph: • Node for each transaction. • Arc from Ti to Tj if Tj holds a lock and Ti • is waiting for it. • Periodically check graph for cycles. • “Shoot” some transaction to break the cycle. • Simpler hack: time-outs. • T1 made no progress for a while? Shoot it.

  22. Detection Versus Prevention • Prevention might abort too many transactions. • Detection might allow deadlocks to tie up resources for a while. • Can detect more often, but it’s time-consuming. • The usual answer: • Detection is the winner. • Deadlocks are pretty rare. • If you get a lot of deadlocks, reconsider your schema/workload!

More Related