Properties of some other significant recovery methods, which uses WAL protocol.
VLM = value Logging Method, OLM = Operation Logging Method.
Buffer Management
During normal processing VLM and OLM write a fetch record whenever a page is read from nonvolatile storage, and end write record every time a dirty page is successfully written back to nonvolatile storage.
. These records identify the super set of dirty pages, that might have in the buffer pool at the time of system failure.
DB2 writes a log record whenever a table space or an index space is opened and another log record whenever such a space is closed, whenever all dirty pages have been written back to nonvolatile storage.
IMS FP does deferred updating and at commit, in a single call to log manager, write all records for a given transaction.
FP minimizes the amount of time locks are held by releasing locks even before the commit log is placed on stable storage.
IMS FF follows steal and force policy.
normal Checkpointing
OLM, VLM quisce all activity in the system and take an operation consistent checkpoint.
DB2, IMS, NonStop SQL, Encompass take fuzzy checkpoints.
DB2 : instead of writing dirty page table, it writes the dirty objects list with a RecLSN for each object.
For MSDB alone, IMS writes their complete contents alternatively on one of two files on nonvolatile storage during checkpoint. Due to deferred updating no uncommitted changes are present.
DEDS : any committed updated pages which have not yet been written to nonvolatile storage are included in the checkpointing records. FP data recovery thus does not need to examine, any log records written before checkpoint.
Partial Rollbacks
Encompass, Nonstop SQL, OLM, VLM, do not support partial transaction rollback.
DB2 supports partial rollbacks for internal use by the system only.
IMS supports partial rollbacks. Savepoint concept is exposed at the application program level; for applications that do not access FP data.
Compensating Log Records
Many systems except IMS FP, write CLRs during normal rollbacks, and during restart rollback also.
VLM does not write CLRs during restart rollbacks.
No CLRs are generated for CLRs themselves.
During restart recovery, Encompass, DB2 write CLR for CLR also. This causes the number of log record writing during repeated restart failures which grows exponentially. We have seen already ARIES avoids this problem.
Log Record Contents
IMS FP writes only redo information. Further it also logs the address of the buffer occupied by a modified page. This information is used during a backup's takeover or restart recovery. This reduces the mount of redo work.
IMS FF logs undo, redo information. Further it logs enough information in its log records for the backup system to track the lock names of updated objects.
Encompass and VLM logs complete undo, redo information.
DB2 and NonStop SQL logs only before and after images of the updated fields.
Since CLS of Encompass and DB2 might be undone, this CLR need to contain redo and undo information.
Page Overhead
Encompass and Nonstop SQL use one LSN on each page to keep track of the state of the page.
VLM uses no LSNs, but OLM uses one LSN.
DB2 uses one LSN and IMS FF : no LSN
If the LSN is not used, then one must use value logging and physical locking attributes.
IMS FP uses a field in the pages of DEDBs as a version number to correctly handle redos after all the data sharing systems have failed.
When DB2 divides an index leaf page into minipages then it uses one LSN for each minipage, besides one LSN for the page as a whole.
Log Passes During Restart Recovery
Encompass and Nonstop SQL make two passes, redo and then undo. Redo passes are started from the beginning of the penultimate successfully checkpoint.
They repeat history before performing an undo pass but not if a backup system takes over.
Locks are first reacquired for the loser's updates and then the rollbacks of losers in parallel with the processing of new transactions, when hot standby takes over.
DB2 takes 3 passes: analysis, redo and then undo.
DB2 starts its redo scan from that point, which is determined using information recorded in the last successful checkpoint.
VLM makes one backward pass and is used to undo. Uncommitted changes on nonvolatile storage and also to redo missing committed changes. No log during these operations.
OLM makes 3 passes : analysis, undo and then redo.
OLM, VLM maintain many lists during the above passes.
Using undo(OLM), if an operation consistent version of the object does not exists on nonvolatile storage, then it restores snapshots of the object. Now starting from a consistent version updates that precede the snapshot log can be done logically,and any committed or in-doubt updates that follow the snapshot are redone logically(redo pass).
IMS reloads MSDB from the file that received their contents during the latest checkpoint. The dirty DEDB buffer in checkpoint are also reloaded into the same buffers.
Then it makes just one forward pass over the log accumulating log records in memory on a per transaction basis and redoes completed transaction's FP updates.
At the end of that (redo) pass, in progress transactions' FF updates are undone. In case of insufficient memory, a backward scan of the log is performed.
Page Forces During Restart
OLM, VLM, DB2 force all dirty pages at the end of restart.
Restart Checkpoint
IMS, OLM, VLM, DB2 take a checkpoint only at the end of restart recovery.
restrictions on Data
Encompass and Nonstop SQL requires that every record have a unique key. This is to guarantee that if an attempt is made to undo a logged action which was never applied to nonvolatile storage version of the data, then this realized and undo fails to achieve idempotency of operations.
IMS does not allow records to be moved freely within a page and it puts some more restrictions.
VLM requires that an object's representation be divided into fixed length unrelocatable quanta.