251 lines
8.5 KiB
Markdown
251 lines
8.5 KiB
Markdown
# 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.
|