ATTRIBUTES OF ARIES

ARIES makes few assumptions about the data or its model. Has several advantages over other recovery methods. Possesses several interesting and useful properties.

1. Support for finer than page-level concurrency control and multiple granularities of locking. Aries supports page-level and record-level locking in a uniform fashion. Recovery not affected by granularity of locking. Allows multiple granularities of locking for the same object.
2. Flexible buffer management during restart and normal processing. As long as WAL protocol is used, buffer manager is free to use any any page replacement policy. In particular, steal policy, no-force policy can be used. These properties lead to reduced demand for buffer star age.
3. Minimal space overhead-only one LSN per page. The permanent (excluding log) space overhead of this scheme is limited to the storage required on each page to store the LSN of the last logged action performed on the page.
4. No constraints on data to guarantee idempotence of redo or undo of logged actions. No restrictions on data w.r.t. unique keys etc. Records can be of variable length. Data can be moved around within a page for garbage collection. Idempotence of operations is ensured since LSN on each page is used to determine whether an operation should be redone or not.
5. Actions taken during the undo of an update need not necessarily be the exact inverses of the actions taken during the original update. Since CLRs are being written during undos, any differences between the inverses of the original actions and what actually had to be done during undo can be recorded in the former.

6. Support for operation logging and novel lock modes. The changes made to a page can be logged in a logical fashion. The undo and redo information for the entire object need not be logged. Only changed fields need be logged. Since history is repeated, for increment and decrement kinds of operations, information about the type of operation and the increment or decrement amount is enough. Novel lock modes based on commutativity and other properties of operations can be supported.

7. Even redo-only and undo-only records are accommodated. While it may be efficient (single call to the log component) sometimes to include the undo and redo information about an update in the same log record, at other times it may be efficient (from the original data, the undo record can be constructed and, after the update is performed in-place in the data record, from the updated data, the redo record can be constructed) and/or necessary (because of log size restrictions) to log the information in two different records. ARIES can handle both situations.
8. Support for partial and total transaction rollback. ARIES allows establishment of savepoints and partial rollback of transactions to such savepoints. Therefore, logically recoverable errors (eg unique key violation) do not result in too much of wasted work.
9. Support for objects spanning multiple pages. When an object is modified, if log records are written for every page affected by that update, ARIES works fine. ARIES itself does not treat multipage objects in any special way.
10. Allows files to be acquired or returned, any time, from to the operating system. ARIES provides flexibility of being able to return files dynamically and permanently to the OS. Such an action is considered to be the one that cannot be undone. It does not prevent the same file from being reallocated to the DBMS.
11. Some actions of a transaction may be committed even if the transaction as a whole is rolled back. This refers to the technique of using the concept a dummy CLR to implement the nested top actions.
12. Efficient checkpoints (including during restart recovery). Checkpoints can be taken even when update activities and logging are going on concurrently (Fuzzy checkpoints). Permitting checkpoints even during restart processing helps reduce the impact of failures during restart recovery.
13. Simultaneous processing of multiple transactions in forward processing and/or rollback accessing same page. Since many transactions could simultaneously be going forward or rolling back on a given page, the level of concurrency supported could be quite high.
14. No locking or deadlocks during transaction rollback. Avoiding locking during rollbacks simplifies not only the rollback logic, but also the deadlock detector logic.
15. Bounded logging during restart in spite of repeated failures or of nested rollbacks. Even if repeated failures occur during restart, the number of CLRs written is unaffected. This is also true if partial rollbacks are nested. No log records are written during the redo pass of restart.

16. Permits exploitation of parallelism and selective / deferred processing for faster restart. Restart can be made faster by not doing all the needed I/Os synchronously one at a time while processing the corresponding log record. ARIES permits early identification of pages needing recovery and the initiation of asynchronous parallel I/Os to read in those pages. Some of the restart processing can be postponed to speed up restart or to accommodate offline devices.

17. Fuzzy image copying (archive dumping) for media recovery. To take advantage of device geometry, the actual act of copying can even be performed outside the transaction system (ie without going through the buffer pool). During media recovery, only one forward traversal of the log is made.
18. Continuation of loser transactions after a system restart. Using history repetition and savepoint concepts, in the undo pass, instead of totally rolling back the loser transactions, each loser could be rolled back only to its latest savepoint. Locks must be acquired to protect the transaction's uncommitted, not undone updates.
19. Only one backward traversal of log during restart or media recovery.

20. Need only redo information in CLRs. Since CLRs are never undone, they need to contain only redo information. So, on the average, the amount of log space consumed during a transaction rollback will be half the space consumed during the forward processing of that transaction.

21. Support for distributed transactions. Whether a given site is a coordinator or a subordinate site does not affect ARIES.
22. Early release of locks during transaction rollback and deadlock resolution using partial rollbacks. Since CLRs are never undone and since a particular non-CLR is never undone more than once, during a (partial) rollback, when the transaction's very first update to a particular object is undone and a CLR is written for it, the system can release the lock on that object.