HP NonStop RDF J-series RVUs Management Manual page 256

In a non-network configuration, a takeover operation occurs in two phases.
• Phase 1 (local undo) undoes transaction data that was incomplete at the backup system at
the time the primary system failed. That is, it undoes transactions that were applied during
the redo phase but the final states of those transactions are unknown by RDF.
• Phase 2 (file undo) only runs if volumes went down on the primary system, transactions
were aborted, and the volumes were never reenabled on the primary system before the
primary system was lost. In that situation, RDF determines what Backout could not undo,
and performs that undo itself.
A network configuration adds a third phase (network undo). See
For more information about undo processing during a takeover operation, see Takeover
Operations in
During the takeover operation, the purger produces lists that identify all transactions that must
be undone by the updaters during the three different undo phases. These are stored in structured
files, but they can be read with the READLIST utility in the RDF software's subvolume. See page
334 for the files that are created for the three undo phases. Additionally, if you have configured
RDF UPDATEREXCEPTION ON, then each updater record information about each audit record
it undoes during the undo passes into its own exception file, thereby giving you an accurate
account of what was undone by each updater. If you have this attribute off, then it only records
the first and last record it has undone. Under normal conditions, the number of transactions
undone by an updater is small and writing to the exception file has not measurable cost. In some
circumstances, writing to the exception file can prolong the RDF takeover operation:
• long-running batch transactions
If a long batch transaction was running on your primary system that did a large number of
updaters at the time the primary system failed, then all of these need to be undone by the
updaters; if UPDATEREXCEPTION is ON, then each update of the batch needs to be undone
and an exception record written.
• Auxiliary Audit and a Comm Problem
If your RDF environment includes extractor-receiver pairs associated with auxiliary audit
trails, then if one extractor-receiver pair has fallen way behind because of a communications
problems, then all affected transactions must be undone by all affected updaters, and this
can lead to a lot of audit being undone with exception records.
RDF Network
•
If you have an RDF Network and one primary system suffers an unplanned outage, then
the amount of undo required by all backup systems is proportional to how long it takes you
to stop all transaction processing on the surviving primary systems. If this is not done quickly,
then all these transactions might need to be undone in order to guarantee business consistency
after the RDF takeover operation completes, which could also generate a large volume of
exceptions records.
When all the updater processes shut down, the purger checks to see if each completed its takeover
processing. If yes, the purger logs RDF event 724. If some updaters stopped prematurely (for
example, double CPU failure), it logs RDF event 725. In the latter case, you only need to be sure
all CPUs are available and then reissue the TAKEOVER command.
It is conceivable that one or more transactions could get committed on the primary database
immediately prior to the TAKEOVER operation but that their commit records did not reach the
backup system before the primary system failure. If that happens, the audit data for the affected
transactions is not committed on the backup system and is instead written to the exception file
if you have RDF UPDATEREXCEPTION ON.
Updater Exception files can be read by the RDFSNOOP utility. For information about using
RDFSNOOP, see
256 Entering RDFCOM Commands
Chapter 5 (page 121).
Appendix B (page 359).
Chapter 14 (page 295).