Takeover Failure; Monitor Considerations; Updater Considerations; Takeover And Triple Contingency - HP NonStop RDF J-series RVUs Management Manual

Takeover Failure

If a double CPU failure occurs and any RDF process pair fails during the takeover operation,
you can restart the operation just by entering the TAKEOVER command through RDFCOM
again. You can ascertain that a takeover operation failed by issuing a STATUS RDF command
and getting a response such as the following:
STATUS RDF (\RDF04 -> \RDF05) is NOT running
A partial RDF TAKEOVER has completed
Also, a takeover failure generates RDF event 725 in the EMS log.

Monitor Considerations

Whether the RDF monitor was started when the initial TAKEOVER command was executed or
not, this process is always started when the TAKEOVER command is reissued.

Updater Considerations

When the purger shuts down at the end of the takeover operation, it examines the context record
of each updater process to determine if that updater has processed all applicable audit data
through to end-of-file in the image trail. If all updaters have processed through to end-of-file,
the purger logs a 724 message to the EMS event log, indicating that the takeover operation
completed successfully. But if it determines that one or more updaters have terminated
prematurely, the purger logs RDF Event number 726 for the first updater that failed and then
logs RDF Event number 725, a general message indicating that the takeover operation did not
complete successfully. If these messages appear in the EMS event log, you must reissue the
TAKEOVER command.

Takeover and Triple Contingency

If you have configured two RDF subsystems for Triple Contingency, then when both takeover
operations complete you must examine the RDF event 735 on each backup system. If both report
the exact same MAT position, then you can designate either system as your new primary, configure
a new RDF system to run from this new primary to the backup, and then resume application
processing on the new primary with full RDF protection.
If each reports a different MAT position, then go to the backup system with the lowest MAT
position and execute the COPYAUDIT command (see
command will copy over all additional audit that the other backup system has. When the
command completes, you then enter a new Takeover command on the local system. When it
completes, the two databases are in complete synchronization and you can then resume application
processing on either backup system, as indicated above.

Checking Exception Files for Uncommitted Transactions

Exception files are used by updaters to store information about each audit record that the updater
undoes during the three possible undo passes. An exception record logs information about a
specific audit record that the updater has undone. This may or may not be useful information
for you. If the volume of audit is small, then logging an exception record for each record undone
might have only a slight performance impact during the takeover operation. If, however, the
volume of audit to be undone by an updater is large (for example, thousands of records), then
logging an exception record for each record undone could slow down the takeover work of each
updater.
You can choose whether you want an exception record for each audit record undone during the
takeover operation when you configure the RDF UPDATEREXCEPTION attribute. If you set it
ON, the updater logs an exception record for each audit record on which it executes undo. If set
OFF, then an exception record is only written for the first and last audit records undone. If you
set UPDATEREXCEPTION OFF, you can still determine which transactions were undone by
using the READLIST utility to read the undo files.
Chapter 10 for details). The COPYAUDIT
Takeover Operations 143