Page 187 - DCAP402_DCAO204_DATABASE MANAGEMENT SYSTEM_MANAGING DATABASE
P. 187
Database Management Systems/Managing Database
Notes before the failure. The recovery scheme must also provide high availability; that is, it must
minimize the time for which the database is not usable after a crash.
11.1 Introduction to Crash Recovery
A transaction may fail because of hardware or a software failure. It is the responsibility of the
recovery manager to handle such failure and ensure ‘atomicity’ and ‘durability’. It attains
atomicity by undoing the uncommitted transactions. It also attains durability by retaining the
committed transaction results even after system crashes.
Under normal execution, transaction manager takes care of serializability by providing locks
when requested. It writes the data to the disk in order to avoid loss of data after the system crash.
11.1.1 Stealing Frames and Forcing Pages
1. Steal Approach: The changes made on an object ‘0’ by a transaction are written onto the
disk even before the transaction is committed. This is because another transaction wants a
page to be loaded and buffer manager finds replacing frame with object ‘0’ as optimal.
2. Force Approach: All the objects in buffer pool are forced to disk after the transaction is
committed.
The simplistic implementation of recovery management is to use no-steal-force approach. With
no steal, the data will not be written until a transaction is committed, hence there is no need of
an undo operation and force approach enables us to write data to the disk after committing,
hence we need not perform redo operation.
Though these approaches are simple, they have certain disadvantages. No steal approach requires
a large buffer pool. Force approach involves expensive I/O costs.
If an object is frequently modified, then if needs to be written onto the disk very frequently
involve expensive I/O operation.
Hence steal and no-force approach is implemented by recovery management. Using this
techniques the page is not written onto disk when the modifying transaction is still active. And
it does-not force a page to be written onto disk, when transaction commits.
11.1.2 Recovery - Related Steps during Normal Execution
The recovery manager, stores the modifications made onto a storage which does not react to
system failures. Such storage is called stable storage.
The modifications made to the data is called log. Recovery manager loads the log onto the stable
storage before the new changes are made.
If a transaction is aborted, then log enables recovery manager to undo the operations and redo
the operations if it is committed.
No force approach does not write data into the disk after the transaction is committed. If a
transaction is committed just before a crash, then the modifications made by transaction will not
be loaded onto the disk. This modified data is reloaded from the stable storage.
Steal approach enables to write data onto the disk before committing. If a crash occurs
before committing, then all the data modified onto the disk must be undone. This is done with
help of log.
180 LOVELY PROFESSIONAL UNIVERSITY
