1. File Processing : Recovery
2005, Spring
Pusan National University
Ki-Joune Li

2. Failure Classification
Transaction failure :
Logical errors: internal error condition
System errors: system error condition (e.g., deadlock)
System crash:
a power failure or other hardware or software failure
Fail-stop assumption: non-volatile storage contents are assumed to not be corrupted by system crash
Database systems have numerous integrity checks to prevent corruption of disk data
Disk failure

3. Recovery Algorithms Recovery algorithms : should ensure
database consistency
transaction atomicity and
durability despite failures
Recovery algorithms have two parts
Preparing Information for Recovery : During normal transaction
Actions taken after a failure to recover the database

4. Storage Structure Volatile storage: Nonvolatile storage:
does not survive system crashes
examples: main memory, cache memory
Nonvolatile storage:
survives system crashes
examples: disk, tape, flash memory, non-volatile (battery backed up) RAM
Stable storage:
a mythical form of storage that survives all failures
approximated by maintaining multiple copies on distinct nonvolatile media

5. Recovery and Atomicity
Modifying the database
must be committed
Otherwise it may leave the database in an inconsistent state.
Example
Consider transaction Ti that transfers $50 from account A to account B; goal is either to perform all database modifications made by Ti or none at all.
Several output operations may be required for Ti
For example : output(A) and output(B).
A failure may occur after one of these modifications have been made but before all of them are made.

6. Recovery and Atomicity (Cont.)
To ensure atomicity despite failures,
we first output information describing the modifications to stable storage without modifying the database itself.
We study two approaches:
log-based recovery, and
shadow-paging

7. Log-Based Recovery A log : must be kept on stable storage.
<Ti, Start>, and <Ti, Start>
< Ti, X, V1, V2 >
Logging Method
When transaction Ti starts, <Ti start> log record
When Ti finishes, <Ti commit> log record
Before Ti executes write(X), <Ti, X, Vold , Vnew > log record
We assume for now that log records are written directly to stable storage
Two approaches using logs
Deferred database modification
Immediate database modification

8. Deferred Database Modification
The deferred database modification scheme
records all modifications to the log, writes them after commit.
Log Scheme
Transaction starts by writing <Ti start> record to log.
write(X) :
<Ti, X, V>
Note: old value is not needed for this scheme
The write is not performed on X at this time, but is deferred.
When Ti commits, <Ti commit> is written to the log
Finally, executes the previously deferred writes.

9. Deferred Database Modification (Cont.)
Recovering Method
During recovery after a crash,
a transaction needs to be redone if and only if both <Ti start> and<Ti commit> are there in the log.
Redoing a transaction Ti ( redoTi) sets the value of all data items updated by the transaction to the new values.
Deletes Ti such that <Ti ,start> exists but <Ti commit> does not.

10. Deferred Database Modification : Example
If log on stable storage at time of crash is as in case:
(a) No redo actions need to be taken
(b) redo(T0) must be performed since <T0 commit> is present
(c) redo(T0) must be performed followed by redo(T1) since <T0 commit>
and <Ti commit> are present
T0: read (A) T1 : read (C) A: = A C:= C write (A) write (C) read (B) B:= B write (B)

11. Immediate Database Modification
Immediate database modification scheme
Database updates of an uncommitted transaction
For undoing : both old value and new value
Recovery procedure has two operations
undo(Ti) : restores the value of all data items updated by Ti
redo(Ti) : sets the value of all data items updated by Ti
When recovering after failure:
Undo if the log <Ti start>, but not <Ti commit>.
Redo if the log both the record <Ti start> and <Ti commit>.

12. Immediate Database Modification : Example
Recovery actions in each case above are:
(a) undo (T0): B is restored to 2000 and A to 1000.
(b) undo (T1) and redo (T0): C is restored to 700, and then A and B are
set to 950 and 2050 respectively.
(c) redo (T0) and redo (T1): A and B are set to 950 and 2050
respectively. Then C is set to 600

13. Idempotent Operation Result (Op(x)) = Result (Op(Op(x))
Example
Increment(x); : Not Idempotent
x=a; write(x); : Idempotent
Operations in Log Record
Must be Idempotent, otherwise
Multple Executions (for redo) may cause incorrect results

14. Checkpoints Problems in recovery procedure by Log record scheme :
searching the entire log records : time-consuming
Discard unnecessary redo transactions already executed.
Checkpoint Method
Marking Checkpoint
Recovery from Checkpoint
Output all log records currently residing in main memory onto stable storage.
Output all modified buffer blocks to the disk.
Write a log record < checkpoint> onto stable storage.

15. Checkpoints (Cont.) In case of failure Tc Tf T1 T2 T3
T1 can be ignored
T2 and T3 redone.
T4 undone Tc Tf T1 T2 T3 T4
checkpoint
system failure

16. Shadow Paging Mechanism maintain two page tables shadow page table
the current page table, and
the shadow page table
shadow page table
state of the database before transaction execution
Shadow page table is never modified during execution
To start with, both the page tables are identical.
Whenever any page is about to be written for the first time
A copy of this page is made onto an unused page.
The current page table is then made to point to the copy
The update is performed on the copy

17. Shadow Page : Example
Old State
New State