ARIES Redo Pass
Redo Pass: Repeats history by replaying every action not already reflected in the page on
disk, as follows:
Scans forward from RedoLSN. Whenever an update log record is found:
1. If the page is not in DirtyPageTable or the LSN of the log record is less than the
RecLSN of the page in DirtyPageTable, then skip the log record
2. Otherwise fetch the page from disk. If the PageLSN of the page fetched from disk is
less than the LSN of the log record, redo the log record
NOTE: if either test is negative the effects of the log record have already appeared on
the page. First test avoids even fetching the page from disk!
Database Management System (PPT) – M V Kamal, Associate Professor
ARIES Undo Actions
When an undo is performed for an update log record
Generate a CLR containing the undo action performed (actions performed during undo
are logged physicaly or physiologically).
CLR for record n noted as n’ in figure below
Set UndoNextLSN of the CLR to the PrevLSN value of the update log record
Arrows indicate UndoNextLSN value
ARIES supports partial rollback
Used e.g. to handle deadlocks by rolling back just enough to release reqd. locks
Figure indicates forward actions after partial rollbacks
records 3 and 4 initially, later 5 and 6, then full rollback
1 2 3 4 4' 3' 5 6 6' 5' 2' 1'
Database Management System (PPT) – M V Kamal, Associate Professor
ARIES: Undo Pass
Undo pass:
Performs backward scan on log undoing all transaction in undo-list
Backward scan optimized by skipping unneeded log records as follows:
Next LSN to be undone for each transaction set to LSN of last log record for
transaction found by analysis pass.
At each step pick largest of these LSNs to undo, skip back to it and undo it
After undoing a log record
For ordinary log records, set next LSN to be undone for transaction to
PrevLSN noted in the log record
For compensation log records (CLRs) set next LSN to be undo to
UndoNextLSN noted in the log record
All intervening records are skipped since they would have been undone
already
Undos performed as described earlier
Database Management System (PPT) – M V Kamal, Associate Professor
Recovery Actions in ARIES
Database Management System (PPT) – M V Kamal, Associate Professor
Other ARIES Features
Recovery Independence
Pages can be recovered independently of others
E.g. if some disk pages fail they can be recovered from a backup while other pages
are being used
Savepoints:
Transactions can record savepoints and roll back to a savepoint
Useful for complex transactions
Also used to rollback just enough to release locks on deadlock
Database Management System (PPT) – M V Kamal, Associate Professor
Other ARIES Features (Cont.)
Fine-grained locking:
Index concurrency algorithms that permit tuple level locking on indices can be used
These require logical undo, rather than physical undo, as in earlier recovery
algorithm
Recovery optimizations: For example:
Dirty page table can be used to prefetch pages during redo
Out of order redo is possible:
redo can be postponed on a page being fetched from disk, and
performed when page is fetched.
Meanwhile other log records can continue to be processed
Database Management System (PPT) – M V Kamal, Associate Professor
Remote Backup Systems
Database Management System (PPT) – M V Kamal, Associate Professor
Remote Backup Systems
Remote backup systems provide high availability by allowing transaction processing to continue
even if the primary site is destroyed.
Database Management System (PPT) – M V Kamal, Associate Professor
Remote Backup Systems (Cont.)
Detection of failure: Backup site must detect when primary site has failed
to distinguish primary site failure from link failure maintain several communication
links between the primary and the remote backup.
Heart-beat messages
Transfer of control:
To take over control backup site first perform recovery using its copy of the
database and all the long records it has received from the primary.
Thus, completed transactions are redone and incomplete transactions are
rolled back.
When the backup site takes over processing it becomes the new primary
To transfer control back to old primary when it recovers, old primary must receive
redo logs from the old backup and apply all updates locally.
Database Management System (PPT) – M V Kamal, Associate Professor
Remote Backup Systems (Cont.)
Time to recover: To reduce delay in takeover, backup site periodically proceses the
redo log records (in effect, performing recovery from previous database state), performs
a checkpoint, and can then delete earlier parts of the log.
Hot-Spare configuration permits very fast takeover:
Backup continually processes redo log record as they arrive, applying the updates
locally.
When failure of the primary is detected the backup rolls back incomplete
transactions, and is ready to process new transactions.
Alternative to remote backup: distributed database with replicated data
Remote backup is faster and cheaper, but less tolerant to failure
more on this in Chapter 19
Database Management System (PPT) – M V Kamal, Associate Professor
