1 Introduction

The recovery subsystem is an essential part of any Relational Database Management System (RDBMS). Functions that are performed by the recovery subsystem include:

1.   Logging of all updates done to the database. Either physical changes to the database may be logged (physical logging, e.g., the bytes in the offset range 20--24 in page 3 of the database changed from <20, 30, 40, 50, 60> to <75, 32, 47, 95, 126>) or the operations performed on the data may be logged (logical logging, e.g., an insert of the <key, record-id> pair <25, 65> was done on the B-tree index on employee ID of relation foo of the database).

2. Supporting the notion of transaction aborts or rollbacks. Every change that the transaction effected on the database must be undone. The log of changes made by the transaction to the database (maintained, as described in (1) above) is used for this purpose.

3. Crash recovery. The data in the database must be protected against crashes. Modern RDBMSs use a buffer pool to cache the most often/recently used pages of the database. If the system crashes before the changes made in main memory make it to disk, the recovery subsystem, on restart, will have to reconstruct the changes. Again, the log is consulted to determine the changes effected. Also, transactions that were in progress at the time of the crash need to be undone.

4. Checkpointing and Savepointing. Checkpointing takes a snapshot of certain key data structures and stores it in the log. This checkpoint is used during restart to minimize the amount of work the system needs to do before everything is back to normal. Savepointing allows transactions to snapshot themselves at various points within themselves, and rollback to any previously made savepoint.

It is clear that logging is an integral part of the recovery subsystem. This project report describes the design and implementation of a log manager for a recovery subsystem based on ARIES [Mohan et al. 92]. The recovery subsystem is a part of a simple, multi-user RDBMS called Minirel.

Section 2 briefly describes how ARIES recovery works. This section also introduces the features expected of a log manager based on ARIES. Section 3 describes Minirel and how an ARIES-based log manager fits into it. Section 4 defines the interface that our log manager provides to other parts of Minirel. Section 5 outlines how the log manager implements the interface and other implementation issues. Sections 7 and 8 enumerate some additional work that can be done to enhance the utility and performance of our log manager and Minirel as a whole, respectively. Finally, Section 9 concludes the report.