Algorithms for Recovery and Isolation Exploiting Semantics: Difference between revisions

Revision as of 17:11, 11 October 2019

Revision as of 20:58, 1 November 2019

Line 1:

In [[computer science]], '''Algorithms for Recovery and Isolation Exploiting Semantics''', or '''ARIES''' is a recovery [[algorithm]] designed to work with a [[no-force]], steal database approach; it is used by [[IBM DB2]], [[Microsoft SQL Server]] and many other [[database system]]s.<ref>{{cite journal|last1=Mohan |first1=C.|last2=Haderle |first2=Donald|last3=Lindsay|first3=Bruce|last4=Pirahesh|first4=Hamid|last5=Schwarz|first5=Peter|title=ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging|journal=ACM Transactions on Database Systems|date=March 1992|volume=17|issue=1|pages=94–162|doi=10.1145/128765.128770}}</ref> [[IBM Fellow]] Dr. [[C. Mohan]] is the primary inventor of the ARIES family of algo.<ref>{{cite web|title=Repeating History Beyond ARIES|url=http://www.vldb.org/conf/1999/P1.pdf|publisher=C. Mohan, Proceedings of the 25th International Conference on Very Large Data Bases, Edinburgh, UK, September 1999.}}</ref>

Three main principles lie behind ARIES

Line 11:

For the ARIES algorithm to work a number of log records have to be created during the operation of the database. Log entries are sequentially ordered with Sequence Numbers.

Usually the resulting logfile is stored on so-called "stable storage", that is a storage medium that is assumed to survive crashes and hardware failures. To gather the necessary information for the logging two [[data structuresstructure]]s have to be maintained: the dirty page table (DPT) and the transaction table (TT).

The dirty page table keeps record of all the pages that have been modified and not yet written back to disc and the first Sequence Number that caused that page to become dirty. The transaction table contains all transactions that are currently running and the Sequence Number of the last log entry they caused.

Line 17:

We create log records of the form (Sequence Number, Transaction ID, Page ID, Redo, Undo, Previous Sequence Number). The Redo and Undo fields keep information about the changes this log record saves and how to undo them. The Previous Sequence Number is a reference to the previous log record that was created for this transaction. In the case of an aborted transaction, it's possible to traverse the log file in reverse order using the Previous Sequence Numbers, undoing all actions taken within the specific transaction.

Every transaction implicitly begins with the first "Update" type of entry for the given TransactionIDTransaction ID, and is committed with "End Of Log" (EOL) entry for the transaction.

During a recovery or while undoing the actions of an aborted transaction a special kind of log record is written, the Compensation Log Record (CLR), to record that the action has already been undone. CLRs are of the form (Sequence Number, Transaction ID, Page ID, Redo, Previous Sequence Number, Next Undo Sequence Number). The Redo field contains application of Undo field of reverted action, and the Undo field is omitted because CLR is never reverted.

Line 49:

== Checkpoints ==

To avoid rescanningre-scanning the whole logfile during the analysis phase it is advisable to save the DPT and the TT regularly to the logfile, forming a checkpoint. Instead of having to run through the whole file it is just necessary to run backwards until a checkpoint is found. From that point it is possible to restore the DPT and the TT as they were at the time of the crash by reading the logfile forward again. Then it is possible to proceed as usual with Redo and Undo.

The naive way for [[Application checkpointing|checkpointing]] involves locking the whole database to avoid changes to the DPT and the TT during the creation of the checkpoint. Fuzzy logging circumvents that by writing two log records. One Fuzzy Log Starts Here record and, after preparing the checkpoint data, the actual checkpoint. Between the two records other log records can be created. During recovery it is necessary to find both records to obtain a valid checkpoint.

== References ==