Database Reference
In-Depth Information
(2) If T starts before an earlier Tn ends, then
(a) Write-set(Tn) is not the same as Read-set(T), and
(b) Earlier transaction Tn completes its write phase before T enters its validation
phase, that is, Start(T) < Finish(Tn) < Validation(T).
Rule 2 (a) above ensures that values written by an earlier transaction are not
read by the current transaction. Rule 2 (b) guarantees that the write operations are
performed serially, not causing conflicts.
DATABASE FAILURES AND RECOVERY
So far, we have concentrated on problems emanating from concurrent processing
of transactions and how concurrent processing could cause data integrity problems.
If concurrent transactions are not processed according to specific concurrency
control protocols, they are likely to leave the database in an inconsistent state.
We now turn our attention to data integrity problems that arise because of
various types of failures. Recall the definition of a transaction as a unit of work that
must be completed successfully to maintain database consistency. You know that in
a large database environment a continuous stream of transactions is accessing the
database all the time. What happens in such an environment if there is a sudden
crash of the disk where the database resides? Just at the moment when disaster
strikes, several transactions could be in flight, unable to complete successfully and
resulting in serious data inconsistency problems. The effects of the partially exe-
cuted transactions must be cleaned up, and the database should be restored to a
consistent state.
We begin by surveying the types of failures that could cause data integrity prob-
lems and examine some ideas on how to recover from these types of failures. Spe-
cific recovery techniques address particular types of failures and how to recover
from them. We will explore these recovery techniques. Recovering from failures and
keeping the database system correct and consistent are primary requirements in a
modern organization.
Classification of Failures
A database system is subject to a variety of failures. When a database system fails
for one reason or another, the processing of transactions stops and the database is
rendered unusable. The action that follows to recover from the interruption and
make the database functional depends on the type of failure. The database and oper-
ating system software automatically handle some error conditions. Other error con-
ditions need special actions. Depending on the severity of the failure, it may take a
while for the recovery process to complete.
Let us list the types of failures and try to classify them. The list describes each
type of failure and also indicates the nature of the recovery process.
Transaction error.
Malfunction of a transaction caused by exception conditions
such as integer overflow, divide by zero, bad input, data not found, resource limit
exceeded, and so on. These are usually handled in the application program. The
Search WWH ::
Custom Search