Summary

• ARIES is a versatile, flexible recovery method which supports a variety of features that are very important in building and operating an industrial strength transaction processing system.

• ARIES accomplishes all the goals that were mentioned in the beginning by logging all updates on a per page basis, using an LSN on every page for tracking page state, repeating history during restart recovery before undoing loser transactions, and chaining the CLRs to the predecessors of the log records that they compensated.

• ARIES can be used not only for database area, but also for implementing persistent object-oriented languages, recoverable file systems and transaction based operating systems.

In the following, we summarise as to which specific features of ARIES lead to which specific attributes that give us flexibility and efficiency.

1. Repeating history exactly, which in turn implies using LSNs and writing CLRs during undos, permits the following:

   # Record level locking to be supported and records to be moved around within a page to avoid storage fragmentation without the moved records having to be locked and without the movements having to be logged.
   # Use only one state variable, a log sequence number, per page.
   # Reuse of storage released by one transaction for the same transaction's later actions or for other transactions' actions once the former commits, thereby leading to the preservation of clustering of records and the efficient use of storage.
   # The inverse of an operation originally performed during forward processing of a transaction to be different from the action(s) performed during the undo of that original action. That is, logical undo with recovery independence is made possible.
   # Multiple transactions may undo on the same page concurrently with transactions going forward.
   # Recovery of each page independently of other pages or of log records relating to transaction state, especially during media recovery.
   # If necessary, the continuation of transactions which were in progress at the time of system failure.
   # Selective or deferred restart, and undo of losers concurrently with new transaction processing to improve data availability.
   # Partial rollback of transactions.
   # Operation logging and logical logging of changes within a page. For example, decrement and increment operations may be logged, rather than the before and after-images of modified data.
   

2. Chaining, using the UndoNxtLSN field, CLRs to log records written during forward processing permits the following, provided the protocol of repeating history is followed.

   # The avoidance of undoing CLRs' actions, thus avoiding writing CLRs for CLRs. This also makes it unnecessary to store undo information in CLRs.
   # The avoidance of the undo of the same log record written during forward processing more than once.
   # As a transaction is being rolled back, the ability to release the lock on an object when all the operations on that object have been undone. This may be important while rolling back a long transaction or while resolving a deadlock by partially rolling back the victim.
   # Handling partial rollbacks without any special actions like patching the log.
   # Making permanent, if necessary via nested top actions, some of the changes made by a transaction, irrespective of whether the transaction itself subsequently rolls back or commits.
   

3. Performing the analysis pass before repeating history permits the following: # Checkpoints to be taken any time during the redo and undo passes of recovery.
   # Files to be returned to the OS dynamically, thereby allowing dynamic binding between database objects and files.
   # Recovery of file-related information concurrently with the recovery of user data, without requiring special treatment for the former.
   # Identifying pages possibly requiring redo, so that asynchronous parallel I/Os could be initiated for them even before the redo pass starts.
   # Exploiting opportunities to avoid redos on some pages by eliminating those pages from the dirty_pages table on noticing e.g. that some empty pages have been freed.
   # Exploiting opportunities to avoid reading some pages during redo, e.g. by writing end_write records after dirty pages have been written to nonvolatile storage and by eliminating those pages from the dirty_pages table when the end_write records are encountered.
   # Identifying the transactions in the in-doubt and in-progress states so that locks could be reacquired for them during the redo pass to support selective or deferred restart, the continuation of loser transactions after restart, and undo of loser transactions in parallel with new transaction processing.