Name: Ling
Huang SID:
15053127 E-mail: hlion@newton.berkeley.edu
Review of
<<ARIES: A Transaction Recovery Method Supporting Fine-Granularity
Locking and Partial Rollbacks Using Write-Ahead Logging >>
This
long paper presents an efficient recovery algorithm, ARIES, which supports
partial rollbacks of transactions,
fine-granularity locking and recovery using write-ahead logging. It is designed
to work with steal, non-force approach. The main points in this paper are as follows:
1.
Main principle
> Repeating history
Restarting after a crash, ARIES redo all the actions of the
DBMS before the crash and brings the system back to the exact state at the time
of crash.
> Write-ahead logging
A log sequence number is used in each page to correlate the
state of a page to the logged updating.
Any modification to database data is first recorded in the
log.
Log must be written to
disk before the change to the database done.
> Logging changes during
Undo
It undos the actions of
transactions that were still active at the time of the crash. Those changes are
logged in order to
ensure
that such an action is not repeated in the event of repeated restarts.
2.
Data Structure
> Log: Every log has a unique LSN. Fields in the log include
PrevLSN, TransID, type, PageID, UndoNxtLSN and other data fields. Log is
written when any actions of updating a page, commit, abort, end and undoing an
update happens. Main types of log include Update Log Records and Compensation
Log Records (CLR). A CLR is generated when an update log record is
undone.
> Page: every page has a page_LSN field, describing the latest
update to the page.
> Transaction table: entry for each active
transaction. Each entry contains TransID, Status and LastLSN and UndoNxtLSN.
>
Dirty page table: entry for each dirty page in the buffer pool. Each entry
contains pageID and recLSN.
3. Recovering procedure
>
Analysis phase
Input: LSN of
the master record;
Output:
RedoLSN: The
location on the log from which the Redo pass must start processing the
log.
Transaction table:
transactions that were in the in-doubt or unprepared state at the time of the
crash and must undone.
Dirty
page table: pages in the buffer pool that were dirty at the time of
crash.
It begins at the most recent checkpoint and then scan forward until
reaching the end of logs. If a log record for a transaction T is encountered,
and entry for T is added to the table; if the end log record for T is
encountered, T is removed; if a log record is encountered for a page P whose
identity does already appear in the dirty-pages table, then an entry is made in
the table with the current log record's LSN as the page's RecLSN.
>
Redo
Redo phase begins with
the log record that has he smallest recLSN of all pages in the dirty page
table, and scans forwards until the end of the log. The action must be redone
unless one of the following conditions holds:
1) The affected page is not in the dirty page table,
or
2) The affected page is
in the dirty page table, but the recLSN for the entry is greater than the LSN
of the log record being checked, or
3) The pageLSN is greater than or equal to the LSN of the log record
being checked. If the logged action must be done, then the logged action is
reapplied and the pageLSN on he page is set to the LSN of the redone log
record.
> Undo
Undo phase scans backward from the end of the log and undo all the loser
transactions in the reverse order in which they appear in the logthat were
active at crash. This is done by continually taking the maximum of the LSNs of
the next log record to be processed for each of the yet-to-be-completely-undone
loser transaction, until no loser transaction remains to be done.