DATA INTEGRITY - Database Design and Development: An Essential Guide for IT Professionals - page 473

program is coded to detect such conditions and take appropriate action. Most of
the time, the transaction aborts and rolls back partial database updates. Usually,
these errors are not considered database system failures; these are local exceptions
at the transaction level.
System error. In this type of failure, the database system enters an undesirable state
such as a deadlock or overflow on some system file or resource. The database system
is unable to continue processing. In such cases, the database may or may not be cor-
rupted. The cause for the error must be determined and corrected before restart-
ing the database.
System failure. This includes failure of hardware, data communication links,
network components, operating system software, or the DBMS itself. Hardware
failure is usually failure of main memory losing volatile storage. The cause for the
failure must be ascertained and corrected. The effects of partial database updates
of transactions in process at the instant of failure must be resolved before restart-
ing the database system.
Disk failure. This is usually a head crash caused by the disk head crashing into the
writing surface of the disk. The extent of the damage must be ascertained, and the
disk has to be discarded if the damage is extensive. The database must be restored
on another disk from a backup copy and recovered from copies of transactions up
to the point of failure. Also, the effects of partial database updates of transactions
in process at the instant of failure must be resolved before restarting the database
system.
Physical failure. This type comprises a variety of problems including power loss,
power surge, fire, disk overwrites, and so on. Full recovery from such a failure
depends on the exact nature of the cause.
Human error. You may include a number of problems in this group such as oper-
ator error, carelessness, sabotage, and theft. Recovery options vary and are difficult.
Recovery Concepts
One of the major concerns about recovering from failures relates to the transac-
tions in progress at the time of a failure. These in-flight transactions do not have a
chance to complete, and the recovery mechanism must address the partial updates
to the database by these transactions. Let us consider one such transaction in
progress at a time of failure. Figure 15-26 shows the transaction in progress at the
instant of failure.
To preserve the consistency of the database, either the effects of the partial
updates must be removed or the updates must be completed. How can we achieve
this? If the system keeps information about all the intended updates of the trans-
action, then the system can use that information either to back out the effects of
the partial updates or to complete the remaining updates. If the partial updates are
backed out, the database is restored to the prior consistent state. On the other hand,
if the remaining updates are completed correctly, the database is taken to a new