Dbms ii mca-ch11-recovery-2013

By C.Aruna Devi(DSCASC) 1
Database Recovery
Techniques
Chapter 11
UNIT V
Data Base Management System
[DBMS]

Database Recovery
Purpose of Database Recovery:
• To bring the database into the last consistent state, which
existed prior to the failure.
• To preserve transaction properties (Atomicity, Consistency,
Isolation and Durability).
Example: If the system crashes before a fund transfer transaction
completes its execution, then either one or both accounts may have
incorrect value.
Thus, the database must be restored to the state before the
transaction modified any of the accounts.

Database Recovery
Types of Failure:
The database may become unavailable for use due to
• Transaction failure: Transactions may fail because of
incorrect input, deadlock, incorrect synchronization.
• System failure: System may fail because of addressing
error, application error, operating system fault, RAM
failure, etc.
• Media failure: Disk head crash, power disruption, etc.

Database Recovery
Data Update:
• Deferred Update: All modified data items in the cache is
written either after a transaction ends its execution or
after a fixed number of transactions have completed their
execution.
• Immediate Update: As soon as a data item is modified
in the cache, the disk copy is updated.

Recovery Techniques
Recovery Techniques Based on Deferred Update
(No Undo/Redo).
Recovery Techniques Based on Immediate
Update.

Recovery Techniques
Recovery Techniques Based on Deferred Update:
Deferred update techniques is to defer or postpone any
actual updates to the database until the transaction
completes its execution successfully, and reaches its commit
point.
A set of transactions records their updates in the log and
cache buffers.
After the transaction reaches its commit point and the log is
force written to disk, the updates are recorded in the
database.

Recovery Techniques Based on Deferred Update
If a transaction fails before reaching its commit point, there is no need
to undo any operations, because the transaction has not affected the
database on disk.
We can state a typical deferred update protocol as follow:
A transaction cannot change the database on disk until it reaches its
commit point.
A transaction does not reach its commit point until all its update
operations are recorded in the log and the log is forced written to disk.

Deferred Update in a single-user system
Deferred Update in a single-user system:
There is no concurrent data sharing in a single user system.
The data update goes as follows:
 A set of transactions records their updates in the log.
 After the transaction reaches its commit point and the log is
force written to disk, the updates are recorded in the database.
After reboot from a failure the log is used to redo all the
transactions affected by this failure.

Deferred Update in a single-user system
(a) T1 T2
read_item (A) read_item (B)
read_item (D) write_item (B)
write_item (D) read_item (D)
write_item (D)
(b)
[start_transaction, T1]
[write_item, T1, D, 20]
[commit T1]
[write_item, T2, B, 10]
[write_item, T2, D, 25] ← system crash
The [write_item, …] operations of T1 are redone.
T2 log entries are ignored by the recovery manager.

Deferred Update with concurrent users
Deferred Update with concurrent users:
This environment requires some concurrency control mechanism to
guarantee isolation property of transactions.
In a system recovery transactions which were recorded in the log after
the last checkpoint were redone.
The recovery manager may scan some of the transactions recorded
before the checkpoint.

T1
T3
T4
T5
system crash
Time
T2
t1 t2
checkpoint
Recovery in a concurrent users environment.
Example:
•When the checkpoint was taken at time t1, transaction T1 had committed, where as transactions T3 & T4
had not.
• Before the system crash at time t2, T3 & T2 were committed but not T4 & T5.
• According to RDU_M method, there is no need to redo the write_item operations of transaction T1.
• Write_item operation of T2 & T3 must be redone because both transaction reached their commit point after
the last check point.
• Recall that the log is force-written before committing a transaction.
• Transaction T4 & T5 are ignored.
• They are effectively canceled or rolled back because none of their write_item operations were recorded in
the database.

(a) T1 T2 T3 T4
read_item (A) read_item (B) read_item (A) read_item (B)
read_item (D) write_item (B) write_item (A) write_item (B)
write_item (D) read_item (D) read_item (C) read_item (A)
write_item (D) write_item (C) write_item (A)
(b) [start_transaction, T1]
[write_item, T1, D, 20]
[commit, T1]
[checkpoint]
[write_item, T4, A, 20]
[commit, T4]
[start_transaction T2]
[write_item, T3, A, 30]
[write_item, T2, D, 25] ← system crash
T2 and T3 are ignored because they did not reach their commit points.
T4 is redone because its commit point is after the last checkpoint.

Two tables are required for implementing this protocol:
Active table: All active transactions are entered in this table.
Commit table: Transactions to be committed are entered in this
table.
During recovery, all transactions of the commit table are redone and
all transactions of active tables are ignored since none of them
reached the database.
It is possible that a commit table transaction may be redone twice
but this does not create any inconsistency because of a redone is
“idempotent.

Recovery Techniques Based on Immediate Update
Recovery Techniques Based on Immediate Update:
 This technique, when a transaction issues an update command, the database can
be updated “immediately” without any need to wait for the transaction to reach
its commit point.
 However an update operation must still be recorded in the log before it applied to
the database.
 Provision must be made for undoing the effect of update operations that have
been applied to the database by a failed transaction.
 This is accomplished by rolling back the transaction and undoing the effect of the
transaction write_item operations.
 If the recovery technique ensures that all updates of a transaction are recorded in
the database on disk before the transaction commits, there is never a need to
REDO any operation of committed transactions.

Undo/Redo Algorithm (Single-user environment):
 Recovery schemes of this category apply undo and also redo for
recovery.
 In a single-user environment no concurrency control is required
but a log is maintained.
 Note that at any time there will be one transaction in the system
and it will be either in the commit table or in the active table.
The recovery manager performs:
 Undo of a transaction if it is in the active table.
 Redo of a transaction if it is in the commit table.

Undo/Redo Algorithm (Concurrent execution):
 Recovery schemes of this category applies undo and also redo to
recover the database from failure.
 In concurrent execution environment a concurrency control is
required and log is maintained.
 Commit table records transactions to be committed and active
table records active transactions.
 To minimize the work of the recovery manager check pointing is
used.
The recovery performs:
 Undo of a transaction if it is in the active table.
 Redo of a transaction if it is in the commit table.

Dbms ii mca-ch11-recovery-2013

More Related Content

What's hot (20)

Similar to Dbms ii mca-ch11-recovery-2013 (20)

More from Prosanta Ghosh (10)

Recently uploaded (20)

Dbms ii mca-ch11-recovery-2013