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

system. To bring the two backup databases into rapid synchronization, you must perform the
following steps:
1. Check the EMS event log on both remote systems after the takeover operations have finished,
and exam each 735 event. This event lists the MAT position of the last record received by
the receiver from its extractor. By comparing this message in each EMS event log, you can
easily identify which backup system received the most audit.
2. On the backup system that received the least audit, use RDFCOM to execute the COPYAUDIT
command. This command copies all the missing audit from the system that received the
most audit to your present local system—the one that received the least audit.
3. Still on your same local backup system, use RDFCOM to execute a TAKEOVER command.
When this command completes execution, the databases on both backup systems will be
fully synchronized and logically identical to each other.
Now, you can configure a new RDF environment between the two backup systems, so that one
operates as the primary and the other as the backup system. Then, you can start your applications
on the new primary and have full RDF protection on the backup.
For situations where the backup systems are very far apart when the primary fails, for example
when an Expand line between systems is down for several hours, you must take steps to ensure
that the audit missing from the system with the least audit is still on disk at the backup system
with the most audit. Normally, an RDF purger process purges image files as soon as it determines
that they are no longer needed. For triple contingency, however, the purger on the system with
the most image audit must retain all files that might be needed for this feature, even if those files
are no longer needed in that purger’s own RDF configuration. To support this need, RDF provides
the PURGER RETAINCOUNT configuration parameter, which lets you specify the number of
image files that should still remain on disk when they are no longer needed. You set
RETAINCOUNT to a value that reflects how far apart you believe your two backup systems are
likely to be, depending on the image file rollover rate expected at your site. (RETAINCOUNT
should always be the same value on both backup systems.)
To achieve this type of protection, it is imperative that you carefully follow the instructions
presented in Chapter 10 (page 255).
Loopback Configuration (Single System)
A loopback configuration is one where the primary and backup systems are the same system.
This configuration is of no use in a disaster protection plan, but can be useful for testing purposes.
One set of disks can be replicated to another set of target disks to provide a copy of the live
database. There are two operational considerations unique to this environment:
• The updaters operate in transaction mode, which means you should not stop TMF before
stopping RDF.
• The RDF takeover operation cannot be performed unless you manually stop the monitor
and extractor processes before issuing the TAKEOVER command or include the ! option in
the TAKEOVER command.
Online Product Initialization
You can initialize RDF/IMP, IMPX, or ZLT while your applications continue to run. This is
particularly useful for installing new versions of RDF into existing production environments
where you cannot afford to stop your applications even briefly to generate a TMF shutdown
timestamp. It is also useful if you encounter a problem for which you would like to reinitialize
RDF without stopping your applications.
For information about this capability, see:
• “Initializing RDF Without Stopping TMF” (page 84)
• “Online Installation and Initialization Without Stopping RDF” (page 85)
• “INITIALIZE RDF” (page 198)
Other RDF Features 59