Topics of discussion: Introduce Selective Redo The problems selective redo introduces in supporting fine-granularity locking with WAL based recovery. Why Aries repeats history.
Usually recovery is performed in 2 passes. System-R performs first undo- pass and then redo-pass. Later it will be shown that his is incorrect when WAL with fine-granularity locking is used.
Selective Redo ; Redoing of actions of committed and in-doubt transactions in redo-pass ( of System-R).
Some systems support only page locking and perform selective redo. This leads to data inconsistencies, if record locking were to be implemented.
When the transaction's action are being rolled back, whether or not undo to be actually performed on the page, CLR is always written. CLR is written even when the page does not contain the update. This is also necessary when handling a failure of the system during restart recovery
The state of a page with respect to a losing transaction is lost, when the page modified first by the losing transaction was subsequently modified by a nonloser transaction's update which had to be redone.
By not repeating a history, the page LSN is no longer a true indicator of the current state of the page.
Undoing an action even when its effect is not present in a page will be harmless only under certain conditions.
Reversing the order of the redo and the undo passes does not solve the problem.
System R recovery method functions correctly even with selective redo with the help of shadow page technique and index and space management changes are not logged, but are redone or undone logically.
ARIES repeats history (instead of performing selective redo) which has the ability to commit some actions irrespective of whether the transaction commits or not.