Page 192 - DCAP402_DCAO204_DATABASE MANAGEMENT SYSTEM_MANAGING DATABASE

Unit 11: Recovery System

Notes

Task Disk failure reasons.

11.4 Recovery and Atomicity

Consider again our simplified banking system and transaction T that transfers $50 from account
i
A to account B, with initial values of A and B being $1000 and $2000, respectively. Suppose that
a system crash has occurred during the execution of T , after output (B A) has taken place, but
i
before output(B B) was executed, where B A and B B denote the buffer blocks on which A and B
reside. Since the memory contents were lost, we do not know the fate of the transaction; thus, we
could invoke one of two possible recovery procedures:
1. Execute T . This procedure will result in the value of A becoming $900, rather than $950.
i
Thus, the system enters an inconsistent state.
2. Do not execute T . The current system state has values of $950 and $2000 for A and B,
i
respectively. Thus, the system enters an inconsistent state.
In either case, the database is left in an inconsistent state, and thus this simple recovery scheme
does not work. The reason for this difficulty is that we have modified the database without
having assurance that the transaction will indeed commit. Our goal is to perform either all or no
database modifications made by T . However, if T performed multiple database modifications,
i i
several output operations may be required, and a failure may occur after some of these
modifications have been made, but before all of them are made.
To achieve our goal of atomicity, we must first output information describing the modifications
to stable storage, without modifying the database itself. As we shall see, this procedure will
allow us to output all the modifications made by a committed transaction, despite failures.
11.5 Log Based Recovery

Recovery algorithms are techniques to ensure database consistency and transaction atomicity
and durability despite failures. Recovery algorithms have two parts:

1. Actions taken during normal transaction processing is to ensure that enough information
exists to recover from failures,
2. Actions taken after a failure to recover the database contents to a state that ensures atomicity,
consistency and durability.
While modifying the database, without ensuring that the transaction will commit, may leave
the database in an inconsistent state. Let us consider an example transaction T that transfers
1
`1000/- from account X to account Y; goal is either to perform all database modifications made
by T or none at all. T modifies x by subtracting `1000/- and modifies Y by adding
1 1
` 1000/-. A failure may occur after one of these modifications has been made, but before all of
them are made. To ensure consistency despite failures, we have several recovery mechanisms.
A log is maintained on a stable storage media. The log is a sequence of log records, and maintains
a record of update activities on the database. When transaction T starts, it registers itself by
i
writing a
<T start>log record
i
Before T executes write(X), a log record <T , X, V , V > is written, where V is the value of X
i i 1 2 1
before the write (undo value), and V is the value to be written to X (redo value).
2

LOVELY PROFESSIONAL UNIVERSITY 185