The document discusses the ARIES transaction recovery method, emphasizing its support for fine-granularity locking and partial rollbacks using write-ahead logging. It outlines the essential phases of the recovery process (analysis, redo, and undo) as well as key principles like write-ahead logging and maintaining a history of transactions. Additionally, it provides insights into related structures like transaction tables and dirty page tables, highlighting how these contribute to database consistency after a system crash.

1. ARIES
A Transaction Recovery Method Supporting
Fine-Granularity Locking and Partial Rollbacks
Using Write-Ahead Logging
C.Mohan et al. 1992
Fatima C. Faurillo February 21, 2017

2. OUTLINE
➤ Background and Motivation
➤ Recovery Methods
➤ Write-Ahead Logging
➤ Shadow Paging
➤ Aries
➤ Three Main Principles of Aries
➤ The Log
➤ Other Recovery Related Structures
➤ Recovering from System Crash
➤ Analysis Phase
➤ Redo Phase
➤ Undo Phase
➤ Other Features
➤ References

3. BACKGROUND AND MOTIVATION
Transaction Management is one of the most important
functionalities of Database Management System
Two most important aspects of Transaction Management
1. Concurrency Control
2. Recovery

4. BACKGROUND AND MOTIVATION
Recovery Manager of DBMS is responsible for ensuring two
important properties of transactions.
Atomicity - either all actions in the transaction occur or none
occur
Durability - if a transaction commits, then its effect must persist

5. BACKGROUND AND MOTIVATION
What happens when system crashes?
Recovery manager is given control and must bring the database
to a consistent state. It is also responsible for undoing the
actions of aborted transactions.
It ensures atomicity by undoing transactions that did not
commit and durability by making sure that all actions of
committed transactions survive.

6. RECOVERY METHODS
Write-Ahead Logging (WAL)
a log of all modifications in the database is written to “stable
storage” (i.e disks, tapes) before the change is made
Shadow Paging
when transaction makes changes to a data page, it creates a
copy called the shadow of a page

7. ARIES
ARIES (Algorithm for Recovery and Isolation Exploiting)
supports partial rollbacks of transactions, fine granularity locking
and recovery using write-ahead logging(WAL).
Three phases:
Analysis Phase
Redo Phase
Undo Phase

8. THREE MAIN PRINCIPLES OF ARIES
1. Write-Ahead Logging
all changes are recorded in logs that are written to stable storage before change in
database object is written to disk
2. Repeating History during Redo
retraces all actions made before the crash and brings the system back to the
exact state that it was in at the time of the crash
3. Logging changes during Undo
changes made during undo are logged to ensure such action is not repeated in
the event of repeated failures

9. THE LOG
Log, sometimes called trail or journal, is a history of actions executed by DBMS.
Every log record is given a unique id called the log sequence number (LSN) which is
assigned in increasing order.
Every page in the database contains the most recent log record that describe the
changes to the page, called PageLSN.
A log is written for each action:
Updating a Page, Commit, Abort, End, Undoing an update
Compensation Log Record (CLR) notes the rollback of a particular change to the
database.
Each corresponds with exactly one other Update Log Record and includes undoNextLSN(LSN
of the next log record that is to be undone)
9

10. Figure 1. Contents of Update Log Record
Ramakrishnan, Raghu and Gehrke, Johannes. Database Management Systems, 3rd Ed. McGraw-Hill (2003).
(http://pages.cs.wisc.edu/~dbbook/)

11. OTHER RECOVERY RELATED STRUCTURES
1. Transaction table contains one entry for each active transaction
2. Dirty Page table contains one entry for each dirty page in buffer pool,
that is, each page with changes not yet reflected on disk
Checkpointing is a process that saves information about active
transactions and dirty buffer pool pages that helps reduce time taken to
recover from a crash. Aries uses fuzzy checkpoints.

12. OTHER RECOVERY RELATED STRUCTURES
Ramakrishnan, Raghu and Gehrke, Johannes. Database Management Systems, 3rd Ed. McGraw-Hill (2003).
(http://pages.cs.wisc.edu/~dbbook/)
Figure 2. Instance of Log, Dirty Page table and Transaction table

13. RECOVERING FROM SYSTEM CRASH
Analysis Phase
1. Determines the starting point of the Redo phase
2. Determines the pages in the buffer pool that were dirty at the
time of the crash
3. Identifies transactions that were active at the time of the crash

14. RECOVERING FROM SYSTEM CRASH
Analysis Phase Algorithm
1. Find the most recent begin_checkpoint log record.
2. Initialize the transaction table and dirty page table to the most
recent checkpoint.
3. Scan forward the records from begin checkpoint to the end of the
log. For each log record, update the transaction and dirty page
table as follows:
If there is an end log record for transaction T1, remove T1 from the transaction table.
If there is a log record T1 that is not in the transaction table, add T1 to the table. If
its in the transaction table, then update T1 lastLSN field.
If there is an update/CLR log record for page P1 and P1 is not in the dirty page table,
add P1 in dirty page table and set recLSN to P1’s LSN.

15. ANALYSIS PHASE EXAMPLE
After system crashes, both
transaction and dirty page tables
are lost.
No previous checkpointing,
initialize tables to empty.

16. ANALYSIS PHASE EXAMPLE
Scanning log 00:
Add T1000 to transaction
table.
Add P500 to dirty page table.

17. ANALYSIS PHASE EXAMPLE
Scanning log 10:
Add T2000 to transaction
table.
Add P600 to dirty page table.

18. ANALYSIS PHASE EXAMPLE
Scanning log 20:
Set T2000 lastLSN to 20.

19. ANALYSIS PHASE EXAMPLE
Scanning log 30:
Set T1000 lastLSN to 30.
Add P505 to dirty page table.

20. ANALYSIS PHASE EXAMPLE
Scanning log 40:
Remove T2000 from
transaction table.
Done scanning.
Redo point starts at 00.
Why?
LSN 00 is the earliest log that
may not have been written to
disk before crash.

21. RECOVERING FROM SYSTEM CRASH
Redo Phase reapplies the update of all transactions, committed
or otherwise.
This repeating history paradigm distinguishes ARIES from other
proposed WAL-based recovery algorithms.

22. RECOVERING FROM SYSTEM CRASH
Actions must be redone unless:
1. Affected page is not in the dirty page table.
2. Affected page is in dirty page table but the recLSN for the entry
is greater than the LSN of the log record being checked.
3. PageLSN is greater than or equal to the LSN of the log record
being checked.

23. REDO PHASE EXAMPLE
Scan forward from the redo point
(LSN 00)
Assume that P600 has been written
to disk. (But it can still be in the
dirty page table.)
Scanning 00:
P500 is in the dirty page table.
recLSN(00)== LSN (00)
PageLSN(-10) < LSN(00)
Redo 00
Redo unless:
1. Affected page is not in the dirty page table.
2. Affected page is in dirty page table and recLSN > LSN of
the log record being checked.
3. PageLSN is >= to the LSN of the log record being checked

24. REDO PHASE EXAMPLE
Scanning 10:
P600 is in the dirty page
table.
recLSN(10)== LSN (10)
PageLSN(10) == LSN(10)
Do not redo 10
Redo unless:
1. Affected page is not in the dirty page table.
2. Affected page is in dirty page table and
recLSN > LSN of the log record being
checked.
3. PageLSN is >= to the LSN of the log record
being checked

25. RECOVERING FROM SYSTEM CRASH
Undo Phase scans backward from the end of the log to undo the
actions of all transactions active at the time of the crash, also
called loser transactions.
ToUndo is a set of prevLSN values of all loser transactions.

26. RECOVERING FROM SYSTEM CRASH
Undo Phase Algorithm:
Repeatedly choose the record with the largest LSN value in the
ToUndo set and process it until ToUndo is empty.
If it is an update record, a CLR is written and restore the data record value
to beforeImage. Use prevLSN value in ToUndo.
If it is a CLR and the undoNextLSN value is not null, use undoNextLSN
value in ToUndo. If undoNextLSN is null, this transaction is completely
undone.

27. UNDO PHASE EXAMPLE
The only loser transaction is
T1000.
ToUndo set is {T1000:30}

28. UNDO PHASE EXAMPLE
The only loser transaction is
T1000.
ToUndo set is {T1000:30}
Undoing LSN:30
Write CLR:undo record log
ToUndo set becomes
{T1000:00}
Undoing LSN:00
Write CLR:undo record log
ToUndo becomes null
Done

29. OTHER FEATURES:
➤ Crashes During Restart
➤ Media Recovery
➤ Periodically making copy
of the database (fuzzy
object)
➤ Other approaches and
Interaction with Concurrency
Control
➤ Supports fine-
granularity locks (record
level locks) and logging
logical operations
Ramakrishnan, Raghu and Gehrke, Johannes. Database Management Systems, 3rd Ed. McGraw-Hill (2003).
(http://pages.cs.wisc.edu/~dbbook/)
Figure 3. Example of undo with Repeated Crashes

30. REFERENCES:
Ramakrishnan, Raghu and Gehrke, Johannes. Database Management Systems, 3rd Ed. McGraw-Hill (2003).
(http://pages.cs.wisc.edu/~dbbook/)
C. Mohan, et al., "ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial
Rollbacks Using Write-Ahead Logging", TODS 17(1), 1992.
https://blog.acolyer.org/2016/01/08/aries/
http://www.slideshare.net/PulasthiLankeshwara/aries-recovery-algorithms