08-10-2012, 03:58 PM
ARIES Recovery Algorithm
ARIES Recovery.ppt (Size: 147 KB / Downloads: 26)
Key Features of Aries
Physical Logging, and
Operation logging
e.g. Add 5 to A, or insert K in B-tree B
Page oriented redo
recovery independence amongst objects
Logical undo (may span multiple pages)
WAL + Inplace Updates
Transaction Rollback
Total vs partial (up to a savepoint)
Nested rollback - partial rollback followed by another (partial/total) rollback
Fine-grain concurrency control
supports tuple level locks on records, and key value locks on indices
More Aries Features
Flexible storage management
Physiological redo logging:
logical operation within a single page
no need to log intra-page data movement for compaction
LSN used to avoid repeated redos (more on LSNs later)
Recovery independence
can recover some pages separately from others
Fast recovery and parallelism
Latches and Locks
Latches
used to guarantee physical consistency
short duration
no deadlock detection
direct addressing (unlike hash table for locks)
often using atomic instructions
latch acquisition/release is much faster than lock acquisition/release
Lock requests
conditional, instant duration, manual duration, commit duration
Buffer Manager
Fix, unfix and fix_new (allocate and fix new pg)
Aries uses steal policy - uncommitted writes may be output to disk (contrast with no-steal policy)
Aries uses no-force policy (updated pages need not be forced to disk before commit)
dirty page: buffer version has updated not yet reflected on disk
dirty pages written out in a continuous manner to disk
Some Notation
LSN: Log Sequence Number
= logical address of record in the log
Page LSN: stored in page
LSN of most recent update to page
PrevLSN: stored in log record
identifies previous log record for that transaction
Forward processing (normal operation)
Normal undo vs. restart undo
Compensation Log Records
CLRs: redo only log records
Used to record actions performed during transaction rollback
one CLR for each normal log record which is undone
CLRs have a field UndoNxtLSN indicating which log record is to be undone next
avoids repeated undos by bypassing already undo records
needed in case of restarts during transaction rollback)
in contrast, IBM IMS may repeat undos, and AS400 may even undo undos, then redo the undos
Normal Processing
Transactions add log records
Checkpoints are performed periodically
contains
Active transaction list,
LSN of most recent log records of transaction, and
List of dirty pages in the buffer (and their recLSNs)
to determine where redo should start
Analysis Pass
RedoLSN = min(LSNs of dirty pages recorded in checkpoint)
if no dirty pages, RedoLSN = LSN of checkpoint
pages dirtied later will have higher LSNs)
scan log forwards from last checkpoint
find transactions to be rolled back (``loser'' transactions)
find LSN of last record written by each such transaction