RDF/IMP, IMPX, and ZLT System Management Manual

Entering RDFCOM Commands
HP NonStop RDF/IMP, IMPX, and ZLT System Management Manual—524388-002
8-100
Command Overview
•
If the communications lines are down, RDF proceeds as if the monitor process is
not running and executes the TAKEOVER command.
If RDF is running with updating on, RDFCOM sends a takeover message to each RDF
process.
If RDF is running with updating off, RDFCOM stops the receiver process and starts the
monitor in takeover mode. The monitor then starts a receiver process and all updater
processes.
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.
•
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 runs the undo.
A network configuration adds a third phase (network undo). Refer to Section 13,
Network Transactions.
For more information about undo processing during a takeover operation, see
Takeover Operations in section 5.
During a TAKEOVER operation, RDF completes all the processing it can on the
backup system, writes information about pending records (data audit records for which
no commit/abort records have been received on the backup system) to the exception
file, and stops RDF on the backup system. You should verify that the takeover was
completed successfully by checking the log for 724 or 725 messages. Message 724
indicates that the takeover completed successfully. Message 725 indicates that it did
not, and you should reissue the TAKEOVER command.
If a double CPU failure occurs and the receiver process pair or an updater process pair
fails during a takeover operation, you can resume the operation just by entering the
TAKEOVER command through RDFCOM again.
Regardless of whether the RDF monitor was started during execution of the previous
TAKEOVER command, it is started when this command is reissued.
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. In such a case, your database administrator
might be able to use RDFSNOOP to examine the affected data pointed to by the
exception file. For information about using RDFSNOOP, refer to Appendix B,
Additional Reference Information.