Restarting RDF
If you want to restart RDF and have it resume processing where it stopped at the previous
shutdown, you can only do so if you have not reinitialized RDF subsystem since the shutdown.
Use the START RDF command to restart RDF. RDF automatically starts with UPDATE ON unless
you explicitly specify UPDATE OFF in the START RDF command.
When RDF restarts, it uses the information in the context files to determine where it last stopped,
and resumes processing from that point.
NOTE:
If you delete and reconfigure TMF, then you must initialize RDF.
Carrying Out a Planned Switchover
Many businesses run online transaction processing (OLTP) twenty-four hours a day. Stopping
applications to perform software or hardware upgrades, repairs, or other maintenance can result
in complications and inconvenience for system users. To minimize such planned outages, you
can 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”
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.
136
Critical Operations, Special Situations, and Error Conditions
Содержание NonStop RDF
Страница 68: ...68 ...
Страница 186: ...186 ...
Страница 260: ...260 ...
Страница 278: ...278 ...
Страница 284: ...284 ...
Страница 290: ...290 ...
Страница 308: ...308 ...
Страница 322: ...322 ...
Страница 336: ...336 ...
Страница 348: ...348 ...
Страница 464: ...464 ...
Страница 478: ......