Understanding Database Recovery Schemes

Database recovery is a crucial process that ensures data consistency and integrity in case of failures such as system crashes, transaction errors, disk failures, or power outages. The goal is to restore the database to a consistent state that existed before the failure occurred. Various schemes are employed for database recovery.

Log-Based Recovery Schemes

One of the most common approaches to database recovery is using a log. A log is a sequence of records that details all update activities in the database. Before an update is made to the database on disk, a log record is written to the log. This log contains information like the transaction identifier, the data item affected, and the old and new values of the data item. There are two main types of log-based schemes:

• Deferred Update: Updates are initially recorded only in the log buffer and are written to the database disk only after a transaction commits.
• Immediate Update: Updates can be applied to the database disk even before a transaction commits.

During recovery using logs, the system reads the log records and undoes or redoes operations as needed to bring the database to a consistent state.

Alternative to Log-Based Recovery: Shadow Paging

While log-based recovery is widely used, there are alternative schemes. One significant alternative is Shadow Paging. This scheme does not rely on a log for undo/redo operations. Instead, it maintains two versions of the page table during the lifetime of a transaction: the current page table and the shadow page table.

How Shadow Paging Works

Let's break down the process:

1. Initially, when the database starts, there is only one page table, which is considered both the current and the shadow page table.
2. When a transaction begins, a copy of the current page table is created. This copy is the shadow page table. The original page table becomes the current page table for the transaction.
3. Any updates made by the transaction are not applied directly to the original database pages pointed to by the shadow page table. Instead, when a page needs to be updated, a new physical page is allocated, and the changes are written to this new page.
4. The entry in the current page table for the updated page is modified to point to the newly allocated physical page. The shadow page table still points to the original, unchanged page.
5. The current page table always reflects the state of the database including the updates made by the active transaction(s), while the shadow page table reflects the database state as it was before the transaction(s) began.

Transaction Commit and Failure Recovery in Shadow Paging

• Commit: When a transaction successfully completes and commits, the current page table is made persistent and replaces the shadow page table. This is typically done by updating a pointer or root entry that indicates which page table is the valid one.
• Failure: If a failure occurs before a transaction commits, the system simply discards the current page table. The shadow page table, which points to the database state before the transaction began, is left intact. The database is then restored to its state before the transaction by simply using the shadow page table as the valid page table. No undo or redo operations are needed for committed or uncommitted transactions using the log as in log-based schemes.

Why Other Options Are Not Database Recovery Schemes

• Demand paging and Prepaging are memory management techniques used by operating systems to load data from disk into main memory. They are not database recovery methods.
• Defragmentation is a process used to reduce the fragmentation of files on a disk drive, improving access speed. It is a file system optimization, not a database recovery method.

Therefore, Shadow Paging is the technique among the given options that serves as an alternative to log-based recovery schemes for database recovery.

Revision Table: Log-Based vs. Shadow Paging Recovery

Additional Information: Database Consistency and Recovery

Database recovery mechanisms like log-based recovery and shadow paging are essential for ensuring the ACID properties (Atomicity, Consistency, Isolation, Durability) are maintained even in the presence of failures. Durability, in particular, requires that once a transaction commits, its changes are permanent and survive system failures. Recovery schemes provide the means to achieve this.

While Shadow Paging avoids the need for undo/redo logic on data pages, it can be inefficient for large databases due to copying the entire page table. Log-based recovery is often preferred in practice, especially for concurrent transactions, although it has its own complexities related to checkpointing and log management.