RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

perform a planned switchover from the primary system to the backup system to keep applications
running while you modify or repair the primary system.
Below, the general steps involved in coordinating a switchover of business operations from the
primary to backup system and back are provided. These only address the aspects of the switchover
itself with regard to RDF operation and general business operations. See the section “How to Plan
for the Fastest Movement of Business Operations to Your Backup System After Takeover” (page
135) further below for a variety of considerations on how to achieve the fastest possible switchover
time because the same issues apply, whether you are moving business operations due to a
switchover (planned outage of your primary system) or takeover (unplanned outage of your primary
system).
Standard Configurations
In a standard RDF configuration (system \A the primary, system \B the backup), the steps for
performing a planned switchover from \A to \B are:
1. On system \A, stop the business applications that access the primary database.
2. On system \A, issue a STOP TMF command.
TMF stops as soon as all outstanding database transactions are either committed or aborted.
It then writes a shutdown record to the MAT. Subsequently, the RDF subsystem shuts down
when all updater processes on the backup system (\B) have reached the shutdown record in
the image trail file. At this point, the primary and backup databases are identical.
3. On system \B, note the local system time; you will need it later.
4. On system \B, restart the business applications.
At this point, the RDF subsystem is stopped, the business applications from system \A are
running on system \B, and all audit records are being queued in TMF audit trails on system
\B.
5. When system \A is ready to resume its normal operations, restart TMF on \A.
6. On system \B, issue an INITIALIZE RDF command using the INITTIME option and specifying
the local system time you noted in step 3.
This action initializes the RDF extractor on \B so that it cannot miss any relevant audit records.
7. On system \B, configure the RDF subsystem to run from \B to \A.
8. On system \B, start the RDF subsystem. The RDF subsystem begins replicating database changes
from \B to \A.
When the extractor for the new RDF subsystem running from \B to \A reports an RTD time of 0:00,
then you know that extractor has caught up and you can then prepare for another switchover
operation to move your application processing back to \A.
The planned switchover repeats the procedure described above, except that you reverse the roles
of systems \A and \B. After doing so, RDF replication once again occurs from \A to \B.
Using STOP RDF, REVERSE and the REVERSE Trigger
The STOP RDF, REVERSE command is a special operation that helps you streamline a switchover
operation to move your business operations from your primary system to your backup system
because you want to perform maintenance involving only your RDF-protected database and you
do not want to stop TMF. The use of the REVERSE trigger executes the various tasks that you need
to accomplish the switchover. Whereas the discussion immediately above involves stopping TMF
and switching over to the backup system, typically because you want to take down the primary
system for maintenance, you would use the STOP RDF, REVERSE operation if you wanted to leave
your primary system up and just switch your business operations involving your RDF-protected
database to your backup system. For this operation to work correctly, you must execute the following
steps:
128 Critical Operations, Special Situations, and Error Conditions