Paper Outline - ARIES: A Transaction Recovery Method

Supporting Fine Granularity Locking and Partial Rollbacks

Using Write-Ahead Logging
C. Mohan D. Haderle B. Lindsay H. Pirahesh P. Schwarz

1 Goals of ARIES
1. Simplicity. The main algorithm needs to be simple in order to not make it error-prone.
2. Operation Logging. Use the concept Log Sequence Number (LSN) on a Write-Ahead Log
(WAL) method to keep track of all actions made.
3. Flexible Storage Management. Efficient support for storage and manipulation of varying
length of data is important.
4. Partial Rollbacks. Support the concept of savepoints and rollbacks to checkpoints.
5. Flexible Buffer Management. The recovery method should make the least number of
restrictive assumptions about the buffer management policies, and take advantage of any
specific policies in effect.
6. Recovery Independence. It should be possible to image copy and perform media recovery
or restart recovery at different granularities rather than the entire database.
7. Logical Undo. The ability (during undo) to affect a page that is different from the one
modified during forward processing.
8. Parellelism and Fast Recovery. Redo and undo processing must be page-oriented in
order to exploit parallelism during the different stages of recovery.
9. Minimal Overhead. Have a good performance during normal execution and restart recov-
ery.

2 Overview of ARIES
• Algorithm for Recovery and Isolation Exploiting Semantics
• Developed at IBM Research in early 1990s
• Guarantees atomicity and durability

2.1 Three Main Ideas of ARIES

1. Write-Ahead Logging (WAL)
• Any change is logged on a ”stable” storage before the database change is flushed on
disk
• STEAL+NO FORCE
2. Repeating History During Redo
• Redo all actions from the latest checkpoint until before the failure to restore the database
to its state before the failure.
3. Logging Changes During Undo
• Undo actions are also logged to make sure these actions are not repeated in case of
failures during recovery.

1
3 Data Structures
3.1 Log Records
1. LSN. Log Sequence Number
2. Type. Type of log record
3. TransID. Identifier of transaction
4. PrevLSN. LSN of the preceding log record
5. PageID. Identifier of data page
6. UndoNxtLSN. The next-to-be-undone LSN
7. Data. Describes the undo/redo action performed

3.2 Page Structure

All dirty updates are done on the data page in the buffer pool. The data page contains the
pageLSN.

3.3 Active Transaction Table (ATT)

The transaction table tracks the state of all active transactions.
• TransID. Transactions ID
• State. Commit state of the transaction.
• LastLSN. LSN of the last action made by the transaction.

3.4 Dirty Pages Table (DPT)

The dirty pages table contains information about dirty pages in the buffer pool.

4 Normal Processing
4.1 Updates
• During a normal execution, each transaction invokes a series or reads and writes, followed
by commit or abort.
• During writes, the data page is fixed in the buffer pool and may be latch in X mode, then
the update is performed.
• All updates are logged first in the buffer log before executing the actual action.
• At the end of the transaction, a COMMIT log is written on the buffer log then the buffer
logs until the COMMIT record are flushed into the disk log.
• After successful commit, a TXN-END record may be written on the buffer log to signal the
system that the transaction logs until the COMMIT record buffer log can now be removed
from the buffer log.

4.2 Rollbacks
• Partial and Total Rollbacks
• A partial rollback of a transaction restores the state of the transaction to a certain savepoint.
• A total rollback restores the data page to a state before the start of the transaction.
• During rollback, the transaction updates are played back until a certain checkpoint or at the
start of transaction.
• At each update record, a compensation log record (CLR) is written on the buffer log before
the rollback action is performed.
• The CLR describes the actions taken to undo the action performed by the transaction.

2
4.3 Transaction Termination
• The prepare record written on log includes the list of update-type locks to be able to
reacquire these locks during system failures.

• A transaction enters an in-doubt state when the final state of the transaction cannot be
determined.
• A transaction in the in-doubt state, can be committed by writing an end record and releasing
its locks. Then, all pending actions must be performed.
• A transaction in the in-doubt state, can be rolled-back by writing a rollback record, discarding
the pending actions, and releasing the locks.

4.4 Checkpoints
• A non fuzzy checkpoint (aka transaction consistent checkpoint prevents all new transac-
tions from executing while waiting for currently running transactions to finish, before creating
a checkpoint.
• An action consistent checkpoint keeps a record of the ATT and DPT. However, it halts
all currently executing actions when creating the checkpoint.

• A fuzzy checkpoint has a start and end checkpoint logs and keeps a record of the ATT and
DPT at the end of the checkpoint.
• ARIES uses fuzzy checkpoints.

5 Restart Processing
1. Analysis Pass: Scan the log until before the crash and determine which transactions com-
mitted and failed.
2. Redo Pass: Repeat all actions

3. Undo Pass: Undo all actions from the latest WAL

5.1 Analysis Pass

1. Scan the log from the latest checkpoint until the log before the failure.

2. If a transaction has a transaction-end record, the transaction is removed from the ATT.
3. If an action is performed by a transaction not in ATT, then add the transaction in the ATT.
4. If a transaction has a transaction commit record, then change the status of the transaction
to committing in ATT.

5. For update records, if a transaction updated a page that is not in DPT, add the page in DPT
and set recLSN=LSN

5.2 Redo Pass

1. Scan the log from the record with the smallest recLSN until the log before the failure.
2. Redo all actions described on each log unless
• affected page is not in DPT
• affected page is in DPT but the record LSN is less than the recLSN

3. Set pageLSN = LSN

4. Write a transaction-end record on the log for all transactions that have committed, and
remove the transactions in the ATT.

3
5.3 Undo Pass
1. Undo all actions from transactions that are in ATT.
2. For each undo action performed, a record in the log is written ahead of time, CLRs.

5.4 Selective/Deferred Restart

• Minimize recovery time and start new transactions immediately.
• Some database objects may take some time to go online, which will cause delay when rolling
back transactions the use these offline database objects.
• We may want to start new transactions while waiting for offline objects, and rollback them
later in parallel with new transactions.
• If deferred restart need to be supported, the following algorithm is suggested.

1. Perform the repeating of history for online objects and postpone for offline objects.
2. Proceed with the usual undo pass, except for transactions (stopped transactions) that fail to
generate CLR due to offline objects.
3. Acquire locks for stopped transactions for actions that are not yet done.
4. When previously offline objects became online, first repeat history and continue undoing
stopped transactions. After undoing these transactions, their held locks are released.

5. Once a lock on the previously offline object is released, new transaction can now perform
actions on this object in parallel with undoing other transactions.

We might still want to start new transactions before completion of rollbacks of loser transactions,
even if none of recoverable objects are offline.
1. first repeat history, and reacquire locks for the uncommitted updates of loser and in-doubt
transactions;

2. start processing of new transactions even if the rollbacks of loser transactions run in parallel
The locks acquired on step 1 is released upon completion of rolling back.

6 Checkpoints During Restart

6.1 Analysis Pass
By taking a checkpoint at the end of the Analysis Pass, it is possible to skip the analysis pass at
the event of failure during the recovery. The ATT and DPT at the checkpoint would be the same
after the recovery phase.

6.2 Redo Pass

It is also possible to take checkpoints anytime during the the redo pass, to reduce the amount of
logs to be redone in case there is a failure before the end of redo pass.

6.3 Undo Pass

Similar to taking checkpoints during analysis and redo pass, when a checkpoints is taken anytime
during undo pass, the entries of ATT and DPT at the checkpoint would be similar to the entries
of these tables at that time.

4
7 Media Recovery
• When a fuzzy image copy operation is initiated, the location of the begin checkpoint record
of the most recent complete checkpoint is noted and remembered along with the image copy
data.
• When a media recovery is required, the image-copied version of the entity is reloaded and
then a redo scan is initiated starting from the media recovery redo point.
• Page-oriented logging provides recovery independence among objects
• Individual pages may be corrupted. An efficient way to recover the corrupted page is to read
to uncorrupted page from the non-volatile storage and bring it up to date by rolling forward
the page state.

8 Nested Top Actions

A transaction execution performing a sequence of actions which define a nested top action consists
of the following steps.

1. ascertaining the position of the current transaction’s last record;

2. logging the redo and undo information associated with the actions of the nested top action;
and
3. on completion of the nested top action, writing a dummy CLR who UndoNxtLSN points to
the log record who position was remembered in step 1.

9 Recovery Paradigms
The following are recovery paradigms of System R that have caused difficulties in achieving the
goals of ARIES.
• selective redo during restart
• undo work preceding redo work during restart recovery
• no logging of updates performed during transaction rollback
• no logging of index and space management information changes
• no tracking of page state on page itself to relate it to logged updates

10 Other WAL-based Methods

10.1 Systems and Recovery Methods Examined
1. IBM’s IMS/VS - hierarchical database system
• IMS Full Function (FF)
• IMS Fast Path (FP) - supports two kinds of databases: main storage database (MSDBs)
and data entry databases (DEDBs)
2. DB2 - IBM’s relational database for the MVS OS
• DB2 Recovery Algorithm
3. Tandem’s Nonstop SQL
• Encompass recovery algorithm
4. Recovery algorithm by Schwarz
• Value logging method (VLM)
• Operation logging method (OLM)

5
10.2 Buffer Management
• Encompass, NonStop SQL, OLM, VLM and DB2 - steal, no force
• IMS FP (MSDBs) - deferred updating

• IMS FP (DEDBs) - no steal policy

• IMS FF - steal, force

10.3 Normal Checkpoint

• OLM and VLM - operation consistent checkpoint
• DB2, IMS, NonStop SQL and Encompass - fuzzy checkpoint

10.4 Partial Rollbacks

• Encompass, NonStop SQL, OLM and VLM - no support
• IMS - supports from version 2 release 1
• DB2 - supports for system internal use only

10.5 Compensation Log Records

• Encompass, NonStop SQL, DB2, VLM, OLM and IMS FF - write CLRs during normal
rollbacks

• Encompass, NonStop SQL, DB2 and IMS - write CLRs during restart rollbacks

10.6 Log Record Contents

• IMS FP - redo information only

• IMS FF, Encompass and VLM - redo and undo information

• DB2 and NonStop SQL - before and after-images of the updated fields
• OLM - description of the update operation

10.7 Page Overhead

• Encompass, NonStop SQL, OLM, DB2 - one LSN per page
• VLM, IMS FF - no LSN

• IMS FP - uses a field in the pages of DEDBs as a version number

10.8 Log Passes During Restart Recovery

• Encompass, NonStop SQL - redo, undo

• DB2 - analysis, redo, undo

• VLM - one backward pass
• OLM - analysis, undo, redo
• IMS FP - one forward pass

• IMS FF - forward pass, undo

10.9 Page Forces During Restart

• OLM, VLM, DB2 - force all dirty pages at the end of restart

6
10.10 Restart Checkpoints
• IMS, DB2, OLM, VLM - end of restart recovery

10.11 Restrictions on Data

• Encompass, NonStop SQL - require that every record have a unique key
• IMS - byte-range locking and logging
• VLM - requires that an object representation be divided into fixed length

11 Attributes of ARIES
1. Support for finer than page-level concurrency control and multiple granularities of locking

2. Flexible buffer management during restart and normal processing

3. Minimal space overhead - only one LSN per page
4. No constraints on data to guarantee idempotence of redo or undo of logged actions.
5. Actions taken during the undo of an update need not necessarily be exact inverses of the
actions taken during the original updates.
6. Support for operation locking and novel lock modes
7. Even redo-only and undo-only records are accommodated.
8. Support for partial and total transaction rollback

9. Support for objects spanning multiple pages

10. Allows files to be acquired or returned, anytime, from or to the operating system.
11. Some actions of a transaction may be committed even if the transaction as a whole is rolled
back

12. Efficient checkpoints (including during restart recovery)

13. Simultaneous processing of multiple transactions in forward processing and/or in rollback
accessing the same page
14. No locking or deadlocks during transaction rollback

15. Bounded logging during restart in spite of repeated failures or of nested rollbacks
16. Permits exploitation of parallelism and selective/deferred processing for faster restart.
17. Fuzzy image copying (archive dumping) for media recovery.

18. Continuation of loser transactions after a system restart

19. Only one backward traversal of log during restart or media recovery
20. Need only redo information in CLRs
21. Support for distributed transactions

22. Early release of locks during transaction rollback and deadlock resolution during partial
rollbacks

12 Reference
C. Mohan, et al., ”ARIES: A Transaction Recovery Method Supporting FineGranularity Locking
and Partial Rollbacks Using Write-Ahead Logging”, TODS 17(1), 1992.