Crash Recovery

 

Failure Classification

1) Transaction Failure

a. The transaction cannot continue because of internal conditions like data mismatch, overflow etc. this is logical error.
b. The transaction cannot continue as the system enter into an undesirable state like deadlock , this is system error

---

2) System crash

a. It is the failure caused due to hardware malfunctioning or software bugs that do not affect data of nonvolatile storage.
b. It is called fail stop assumption.

---

3) Disk failure

a. It is the failure caused due to head crash or data transfer failure.
b. Multiple backups are used to recover from this failure.

---

Recovery and Atomicity

Crash Recovery

- Crash recovery is the scheme in a database system that can restore the database system to the consistent state that existed before crash.
- The time for recovery must be minimal.

---

Log Based Recovery

- Log is a sequence of log records, recording all the database update activities.
- When transaction starts, it registers itself by writing a log record.
- Before T: executes write (x), a log record is written, where v1 is value of x before write and v2 after write.
- When t finishes, the log record is written.

---

Deferred Database Modification

- It records all modification to the log , but defers all the writes to after partial commit
- If system crashes before completion of transaction or if transaction is aborted , the information on the log is ignored
- Transaction starts by writing record to log.
- A write (X) results in log record where V is the new value of X
- The write is not performed at this time
- When T: partially commits, is written to log.
- Log records are read and execute deferred writes.
- The recovery scheme uses following procedures:
- Redo (T:) sets the value of all items updated by transaction T: to the new values which can be found in log
- Executing redo () several times must be equivalent to single execution.
- Redo is necessary if both and are in the log.

---

Immediate database modification

- It allows modifications as soon as write operation is executed.
- It is called uncommitted modification
- Update logs consist of both old value and new value.
- The recovery scheme uses:
- Undo (T :) restores value of all data items updated by T: to their old values, going backwards from last log record.
- Redo (T :) sets value of all data items updated by T: to their new values, going forward from first log record.
- Redo is required if (T: START) and both are present.
- Undo is performed first.
- Undo is required if (Start > is present but is absent.

---

Checkpoints

- Searching a log is time consuming.
- It is unnecessary to redo transactions which already o/p updates to database.
- It does not permit any updates to be performed while checkpoint is in progress.
- It outputs all modified buffer blocks to disk when checkpoint is performed.
- It allows streamlining of recovery procedure.
- If a record commit before checkpoint record. During recovery, no redo is necessary on that operation.
- The system examines the log backward from the end.
- For all TX in T without TX commit in the log, execute undo TX
- For all TX in T with TX commit in the log execute Redo TX.

---

Shadow Paging

- It is useful if transaction execute serially
- The current page table and shadow page table are maintained during the lifetime of a transaction.
- Shadow page table is stored in nonvolatile storage with state prior to transaction.
- It is not modified during execution.
- Only current page table is used for access during execution.
- It may cause commit overhead, data fragmentation and garbage collection.

---

Advanced Recovery Techniques

- It supports high concurrency lacking techniques which release locks early.
- Physical undo cannot be performed.

---

Logical Undo

- It allows undo logically i.e. insertion can be undone by executing deletion.

---

Operation Logging

- When operation starts is logged.
- When operation completes, is logged where U contains information for logical undo
- If operation not completed physical undo
- If operation completed logical undo

---

TxN rollback

- If log found , perform undo and log a special redo-only log record
- If is found, rollback logically using undo information U.
- At the end generate record
- Skip all log records for T: until is found .
- If redo-only record is found, ignore it .
- If is found,
- Skip all log records for T: until is found
- Stop scan when is found.
- Add to log.

---

1. In redo phase
- Initially undo list contains {T0,T1}
- It finds T1 commit, so t1 is removed from undo list , t1 is redone = undo list = T0
- It finds t2 start so t2 is added to undo-list = undo=list {T2}
- It finds t0 abort so t0 is removed. = undo-list = {t2}

2. In undo phase
- It scans log backward from the end.
- When it finds t2 updating a, the old value of a is restored and redo only log record written to log.
- It finds start record of t2 then abort t2 is added to log.
- Undo-list is now empty, so undo phase terminates.