Overview of ARIES

• ARIES keeps track of changes made to the DB by following the WAL protocol
• Updates performed during partial or total rollbacks are kept track of by using CLRs
• When the undo of a log record causes a CLR to be written, the CLR besides containing a description of the compensating action for redo purposes, is made to contain the UndoNxtLSN (see Figure 5) pointer which points to the predecessor of the just undone record
• The UndoNxtLSN pointer allows us to determine precisely how much of the transaction has not been undone so far
• It tells the system from where to continue the rollback if a system failure were to interrupt the completion of rollback
• The system supports logical undo

 
Figure 3: Partial rollback example

 
Figure 4: Problem of compensating compensations or duplicate compensations, or both

 
Figure 5: ARIES' technique for avoiding compensating compensations and duplicate compensations

 
Figure 6: Restart processing in different methods

During restart recovery, see Fig, three passes are performed to restore the state of the DB

• Analysis Pass
  • restore dirty pages information and transactions that were in progress when crash occurred
  • determine RedoLSN form dirty pages
  • prepare list of transactions that are to be rolled back
  • for each in-progress transaction determine the LSN of the log record last written
• Redo Pass
  • repeat history, i.e. perform the logged updates of committed and non-committed transactions
  • no logging is performed when the updates are redone
• Undo pass
  • all loser transactions' updates are rolled back, in reverse chronological order, in a single sweep of the log
  • 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 transactions, until no transaction remains to be undone
  • when a non-CLR is encountered for a transaction during the undo pass, if it is an undo-redo or undo-only log record then its update is undone
  • the next record to process is determined by looking at the PrevLSN of that non-CLR
  • when a CLR is encountered during undo, it is just used to determine the next log record to process by looking at the UndoNxtLSN field of the CLR