G4G0-1/Semester 2/Database Systems/Week 7/Week 7 Database Systems.md

Deadlock

An impasse that may result when two or more transactions are waiting for locks held by the other to be released. ex.

Breaking a Deadlock

Abort one or more transactions. If deadlock occurs, DBMS will

• Automatically abort one transaction
• Release locks, allow other transactions to continue
• Restart aborted transaction

Handling Deadlock

• Timeouts
• Prevention
• Detection and recovery

Timeouts

Transactions that request a lock will only wait a system-defined amount of time. If lock not granted within the period,

• Lock request times out
• DBMS assumes deadlock
• Transaction aborted and restarted

Prevention

DBMS looks ahead to see if a transaction causes deadlock. Order transactions using transaction timestamps with the following methods:

Wait-Die

Only older transaction can wait for a younger one. If a younger transaction requests a lock held by an older one, the younger one is aborted then restarted with the same timestamp, so will eventually become the oldest active transaction and will not die.

Wound-Wait

If an older transaction requests a lock held by a younger one, the younger one is aborted.

Summary of Prevention Techniques

Deadlock free Wait-Die, transactions only wait for younger transactions, no cycle Wound-Wait, transactions only wait for older transactions, no cycle Both may cause transactions to be aborted and restarted needlessly, even if they would not cause a deadlock.

Deadlock Prevention and Recovery

DBMS allows deadlock to occur, recognises and breaks it. DBMS uses a wait-for-graph (WFG) that shows transaction dependencies A WFG is generated by creating a node for each transaction, and an edge ( Ti -> Tj ). If Ti is waiting to lock an item locked by Tj. Deadlock exists if the WFG contains a cycle. A WFG is created at regular intervals

Wait-For-Graph Example 1

Example 2

Edge Ti -> Tj, if Ti waiting to lock item locked by Tj Since the WFG contains a cycle, deadlock exists.

Example 3

• Graph contains several cycles, deadlock exists

Recovery

Several issues that DBMS needs to address

• Selecting deadlock victim that will minimise cost of breaking deadlock
  • May be better to abort transaction that has just started, rather than one that has been running longer.
  • May be better to abort transaction that makes little change to database, rather than one that makes a significant change
• Avoiding starvation
  • Occurs when same transaction is chosen as victim, preventing completion
  • DBMS may try to avoid this by storing a count of abortions of a transaction.

Tutorial

1. .
   1. Deadlock occurs when one or more transactions are held by each other, and neither can continue
   2. The DBMS detects deadlock by utilising a WFG, and checking for cycles
   3. The only way to break a deadlock is by aborting one or more transaction.
2. .

Transaction	Locked	Waiting For
T1	X
T2	Z
T3		Z

1. There is no deadlock since there are no cycles.

2. There may be a deadlock, since there are multiple cycles in the WFG

Database Recovery Part 1

Database recovery is the process of restoring the database to a correct state after a failure

Types of Failures

• Media Failures
  • Hard Disk head crashes
  • Loss of secondary storage
• System Crashes
  • Hardware or software errors
  • Results in loss of primary storage ( RAM )
• Application software errors
  • Logical errors in programs that access the database
  • Causes one or more transactions to fail
• Carelessness
  • Unintentional destruction of data by users or operators
• Sabotage
  • Intentional corruption or destruction of data, hardware, or software facilities
• Natural disasters
  • Fires, floods, solar flares, earthquakes, power failure, bit flips, etc.

Facilities Required for Recovery

Log File ( Journal )

• Keeps track of transactions and database changes Backups / Snapshots
• Periodic ( Incremental ) copies of database and journal Checkpoint facility
• Used to make recovery more efficient DBMS recovery subsystem ( Recovery Manager )
• Allows system to restore the database to a consistent state during a failure

Just having backups is not a solution if the facility to recover ( backup protocol ) does not exist.

Buffers

The database buffers occupy an area of primary storage from which data is transferred to and from secondary storage.

Only when buffers have been written to secondary storage can any updates be regarded permanent.

Flushing can be triggered by:

• Commits
• Buffer full

Effects of Failure

• Loss of primary storage ( buffer loss )
• Loss of database on secondary storage

DBMS recovery subsystem uses techniques that minimise effects

Atomicity and Durability

Recovery manager is responsible for maintaining atomicity and durability of transactions in event of failure.

Atomicity

All operations of transaction are performed, or none.

• Recovery manager ensures all effects of committed transactions reach the database, and effects of uncommitted transactions are undone or ignored.

Durability

Effects of committed transactions are permanent

• Effects must survive both loss of RAM and disk storage.

Recovery Management

System Failure

• Transaction can commit once writes are made to database buffers.
• Updates made to buffer are not automatically written to secondary storage.
• There may be delay between committing and writing to secondary storage
  • If system fails during this delay, recovery manager must ensure updates reach the copy of the database on secondary storage.
• If system failure occurs:
  • Database buffers are lost
  • Copy of the database on secondary storage may be incorrect.

Log File ( Journal )

To keep track of database transactions, the DBMS maintains a journal. Two or three copies of the log file are kept on secondary storage due to the importance in the recovery process. If the system fails, the log file is examined to see which transactions to redo / which transactions to undo or ignore.

Contents of Journal

• Transaction identifier
• Type of log record
  • Start, insert, update, delete, abort, commit
• Identifier of data item affected by database action
  • Insert, delete, update
• Before Image
  • Value of data item before operation of log entry
• After Image
  • Value of data item after operation of log entry
• Log management information
• Checkpoint records

Data Entries

Start_transaction( T ) - Records transaction T starts execution Write_item( T, X, old_value, new_value ) - Records transaction T changes the value of database item X from the before image to the new image. Read_item( T, X ) - Records transaction T reads the value of database item X. Not always logged. Commit( T ) - Records transaction T has completed all accesses to the database successfully and its effect can be recorded permanently to the database. Checkpoint - Used to make recovery more efficient. Covered in Part 2.

Example 1

Example 2

Schedule: Log File:

Recovery Rules

• Identify transactions that were committed.
• Undo / Ignore uncommitted transactions, depending on protocol.
• Redo committed transactions.

Undoing Transactions

• If transaction crash occurs, recovery manager may undo transactions.
• This is achieved by examining the transaction log and for every write entry, setting the value of item X in the database to the old value.
• Undoing a number of write item operations from one or more transactions from the log must proceed in the reverse order from the order in which the operations appear in the log.

Redoing Transactions

• For every write entry in the transaction log, the value of item X in the database is set to the new value.
• Redoing a number of write operations from one or more transactions from the log must proceed in the same order in which the operations were written in the log.