HP NonStop RDF, Руководство по управлению

Страница: 132 / 478

1. Issue the RDFCOM UNPINAUDIT command. If you have only one RDF subsystem
configured on your primary system and the control subvolume is the name of the primary
system, then this is a simple operation. If, however, you have multiple RDF subsystems
configured on the primary system, each with its own set of extractors, then you may need
to issue the UNPIN audit command for each RDF subsystem. You do this by starting
RDFCOM, and then for each RDF subsystem you issue the OPEN command with the name
of RDF subsystem's control subvolume, and then issue the UNPINAUDIT command. When
you have issued the UNPINAUDIT command for each control subvolume, then the file is
unpinned by TMF.
2. Issue the STOP TMF command. While stopping RDF does not unpin an audit trail file,
stopping TMF does.
There is a special circumstance that has caused trouble for some customers. Assume you are
running RDF to protect your primary database. Now assume that someone configures a small
RDF test subsystem, starts that test subsystem, stops it, and then deletes the RDF control
subvolume on the primary and backup systems to eliminate all vestiges of that test subsystem.
In doing this, the person performing the test has omitted one critical task - issuing the
UNPINAUDIT command for that subsystem before deleting the control subvolume. Why is this
a problem? Remember that when this RDF test subsystem was started, its extractor pinned the
current audit trail file, and this file remains pinned even after that RDF subsystem was stopped.
To complicate this problem further, the control subvolume was deleted. To recover from this
problem, recall that TMF generates an event when it cannot unpin a file because of RDF and
recall that the control subvolume for the RDF subsystem that has the file pinned is named in the
event. In this example, however, the control subvolume does not even exist because it was deleted
at the end of the test. If you find yourself in this situation, then you must configure an RDF
subsystem with the name of the control subvolume listed in the TMF event. Once you have
configured it, you can then issue the RDFCOM OPEN command, specifying this control subvolume
and then issue the UNPINAUDIT command.
CAUTION: To avoid problems like that described immediately above, always be sure that you
issue the UNPINAUDIT command before you delete an RDF control subvolume.
Stopping RDF
If the communications lines between the primary and backup systems are up, there are two ways
to stop RDF:
1. Issue a STOP RDF command on the primary system.
2. Issue a TMFCOM STOP TMF command on the primary system. After the RDF updaters
have reached the TMF shutdown record, RDF stops and then TMF stops.
If the communications lines between the two systems are down and you want to stop RDF, you
must issue the STOP RDF command on both the primary and backup systems.
Stopping RDF leaves the backup database in an inconsistent state and also leaves the audit trail
file last opened by the extractor pinned.
CAUTION: If the primary system crashes, RDF processes on the backup system remain running.
If you do not execute a takeover and are able to bring the primary system back up, you must
stop the RDF processes on the backup system before you restart RDF on the primary system.
While the primary is down issue STOP RDF on backup. Otherwise, issue the following TACL
command on the backup system: STATUS *, PROG, $SYSTEM.RDF.*, STOP (assuming the RDF
SOFTWARELOC is $SYSTEM.RDF).
For each shutdown procedure, the RDF receiver and updater processes write their current context
information to the RDF context file before stopping. If you restart but do not reinitialize RDF,
the product retrieves the context information from the context file. The context information
132 Critical Operations, Special Situations, and Error Conditions