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: 1.Recovery (Retablering ) 2.Concurrency control (Samtidighedskontrol ) 3.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. 1.Why must all answers to the user about the result of the updates only be send in the second phase of 2PC? 2.What should the user do if the user does not get an answer from the updating program?

6. Layout of the DBMS log record: Record identification Transaction identification Operation code Record before image Record after image Insert Delete Update Begin transaction Commit/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. Two-Phase-Commit (2PC) protocol Exercise. In the two phase commit protocol, all transactions are executed in two phases separated by the Commit. In case of a failure, all transactions in the first phase are removed from the database by writing the corresponding record ”Before image”. In case of a failure, all transactions in the second phase are recovered by writing the corresponding record ”After image”. How is it possible to define the commit time in such a way that the DBMS after a power failure knows the phases of a given transactions?

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

10. Restart by using DBMS checkpoint data: crash! –Transactions T1, T2 & T3 should be durable. –T4 & T5 should be aborted. T1 T2 T3 T4 T5 Checkpoint Undo-queue. Undo-queue. Trans2 Trans4 Trans4Trans5 Redo-queue. Redo-queue. Trans2 Trans3

11. How would you recommend to restart?

12. 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?). -----------------------------------------------

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

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

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

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

17. 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.

18. 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.

19. End of session Thank you !!!

20. 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!

21. 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.

22. 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.

23. 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!