RDF System Management Manual for H-Series RVUs (RDF 1.8)

If you omit the exclamation point, RDFCOM prompts you to ensure that you really want to
perform a takeover. If you answer yes (Y), RDFCOM attempts to contact the primary system. If
the primary system responds, the TAKEOVER command is aborted immediately. If the primary
system is inaccessible, Expand returns an error (which could take several minutes to happen).
The "!" eliminates both the prompt and the subsequent delay.
Usage Guidelines
The TAKEOVER command is customarily issued when the primary system fails or otherwise
becomes unavailable, and makes the backup database the primary database.
CAUTION: The TAKEOVER command is not a normal operational command. Operators should
never issue this command strictly on their own initiative. Issue this command only when
specifically told to do so by someone in high authority.
For takeover considerations in a ZLT environment, see Chapter 17 (page 309).
When you issue a TAKEOVER command without the exclamation point, RDF determines whether
the monitor and master extractor processes are running on the primary system:
• If the communications lines are operational and both the monitor and master extractor
processes are still running, the TAKEOVER command fails.
• If the communications lines are down, RDF proceeds as if either the monitor or master
extractor 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). See Chapter 14 (page 275).
For more information about undo processing during a takeover operation, see Takeover
Operations in Chapter 5 (page 121).
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
240 Entering RDFCOM Commands