91 lines
3.1 KiB
Markdown
91 lines
3.1 KiB
Markdown
# [Undoing & Redoing Transactions](Semester%202/Database%20Systems/Week%207/Week%207%20Database%20Systems.md####Undoing%20Transactions)
|
|
|
|
# Deferred Update Protocol
|
|
|
|
Updates not written until after transaction has reached commit point.
|
|
If transaction fails before committing, no modification is made to database, hence no undoing is required.
|
|
May be necessary to redo updates of committed transactions as effect may not have reached database.
|
|
|
|
## Procedure
|
|
|
|
Redo transaction is both \<T1 start> and \<T1 commit> are present in the log
|
|
|
|
### Example
|
|
|
|
|
|
Failure in different places:
|
|
|
|
In case(a), no commit is present, so no redo or undo is required.
|
|
case(b), T0 commits, but T1 does not, hence T0 is redone.
|
|
case(b), T0 and T1 commits, so both are redone.
|
|
|
|
# Immediate Update Protocol
|
|
|
|
Updates applied as they occur.
|
|
Following a failure, redo updates of committed transactions.
|
|
Undo effects of transactions uncommitted.
|
|
If no commit record, transacation was active and must be undone.
|
|
Undo operations performed in reverse order in log.
|
|
In recovery, use log to undo or redo.
|
|
|
|
## Protocol
|
|
|
|
Undo
|
|
|
|
- If <Ti,start> is in the log but <Ti,commit> is not then restore the value of all data items updated by Ti to their old values, going backwards from the last log record for Ti.
|
|
Redo
|
|
- If <Ti,start> and <Ti,commit> are both in the log then set the value of all data items updated by Ti to the new values, going forward from the first log record for Ti
|
|
|
|
### Example
|
|
|
|
|
|
|
|
# Checkpoints
|
|
|
|
After failure, may not know how far back to search log.
|
|
Checkpoints limit log searching, made automatically by DBMS
|
|
Creation of checkpoints schedules at predetermined intervals.
|
|
Definition: Checkpoints are points of sync between database and log file. All buffers are written to secondary storage.
|
|
|
|
## Procedure
|
|
|
|
1. Write to secondary storage
|
|
- All log records
|
|
- All modified buffer blocks to database.
|
|
- Checkpoint record to log file which contains identities of transactions active at time of checkpoint
|
|
2. Resume processing.
|
|
|
|
|
|
|
|
### Example 1 ( Immediate )
|
|
|
|
- Starts at t0, fails at tf.
|
|
- T1 and T6 have to be undone
|
|
- In absence of other info, recovery manager has to redo T2, 3, 4, and 5.
|
|
- 
|
|
### Example 2 ( serial with checkpoint, Immediate )
|
|
|
|
- Dotted lines = checkpoints
|
|
- T1 is safe since updates are written to disk
|
|
- T4 needs to be undone
|
|
- T2 and 3 need to be redone
|
|
- 
|
|
### Example 3 ( concurrent with checkpoint, Immediate )
|
|
|
|
- T2 and 3 safe since written to disk
|
|
- T1 and 6 need to be undone.
|
|
- Since checkpoint, redo T4 and 5.
|
|
- 
|
|
# Purpose of Recovery Log File
|
|
|
|
- Scan log backwards
|
|
- Create undo / redo lists
|
|
- Undo List: Transactions active at time of crash
|
|
- Perform undo(T) for every transaction in list
|
|
- Stop when reaching \<T, start> for every transaction in list.
|
|
- Redo List: Transactions committed after last checkpoint
|
|
- Redo for each transaction in list.
|
|
|
|
## Example of Log Use ( Immediate )
|
|
|