2.3 Logging and the Recovery Subsystem

Many database management systems make a claim like the following:

Our system has an integrated physical and logical recovery mechanism that protects database integrity in case of hardware and software failures.

The claim is exaggerated, to say the least. After all, an arbitrary software failure could transform a good database state to an arbitrarily erroneous one. (Even the failure to use the serializability isolation level could spoil the integrity of the data as we illustrated earlier.) Similarly, enough hardware failures could cause data to be lost or corrupted. For the best database management systems, the truth is much closer to the following:

Our system can protect database integrity against single hardware failures (of a processor, network, or any disk drive) and a few software failures (failures of the client, a few addressing errors within the server, and fail-stop crashes of the operating system).

Specifically, two kinds of hardware failures can be tolerated:

1. A fail-stop failure of a processor and erasure of its random access memory. (Fail-stop means that when the processor fails, it stops. On the hardware of many vendors such as IBM and HP, redundant checking circuitry stops the processor upon detection of failure.)

2. The fail-stop failure of a disk, provided enough redundant disks are available.

Systems that use mirrored disks, dual-powered controllers, dual-bus configurations, and backup processors can essentially eliminate the effect of such errors. In a still relevant paper, Jim Gray reported that Tandem Non-Stop systems have relegated hardware...