Overview of DBMS recovery and concurrency control:

Eksemplerne er fra kapitel 3 I bogen:

Lars FankDatabaser

Teori og PraksisISBN 87-571-2397-7

Overview of DBMS recovery and concurrency control:

1. Recovery (Retablering )

2. Concurrency control (Samtidighedskontrol )

3. Concurrency control versus availability (Samtidighedskontrol kontra stor tilgængelighed).

Atomic transations:

Why should a database transaction be atomic?

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?

Layout of the DBMS log record:

Recordidentification

Transactionidentification

Operationcode

Record beforeimage

Record afterimage

InsertDeleteUpdateBegin transactionCommit/Abort

What is the operation code used for when the recovery program reads the log file for roll back recovery?

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.

Desired behavior after DBMS crash:

crash!

– Transactions T1, T2 & T3 should be durable.

– T4 & T5 should be aborted .

T1T2T3T4T5

Checkpoint

Restart by using DBMS checkpoint data:

crash!

– Transactions T1, T2 & T3 should be durable.

– T4 & T5 should be aborted .

T1T2T3T4T5

Checkpoint

Undo-queue. Undo-queue.Trans2 Trans4Trans4 Trans5

Redo-queue. Redo-queue.Trans2Trans3

How would you recommend to restart?

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

-----------------------------------------------

DBMS Implementation of ACID Properties:

Logging and Recovery: Guarantees Atomicity and Durability.

Concurrency control: Guarantees Consistency and Isolation.

Overview of DBMS recovery and concurrency control:

1. Recovery (Retablering )

2. Concurrency control (Samtidighedskontrol )

3. Concurrency control versus availability (Samtidighedskontrol kontra stor tilgængelighed).

Two phase locking (2PL):

All locks must be obtained in first phase of 2PLand 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?

Deadlock illustration

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

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.

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.

End of session

Thank you !!!Thank you !!!

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!

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.

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.

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!