RDF System Management Manual

Network Transactions
HP NonStop RDF System Management Manual—524388-003
13-15
RDF Networks and ABORT or STOP RDF
Operations
RDF Networks and ABORT or STOP RDF
Operations
If no network transactions are active, you can stop RDF on any subsystem at any time
without affecting the other systems in an RDF network. The same is true with regard
to an RDF monitor process aborting its RDF subsystem.
There is, however, one exceptional situation. The RDFNET process runs on the
network master’s primary system. For every primary system in the RDF network, the
RDFNET process maintains a special file on its PNETTXVOLUME volume. If the
communications line to one of those primary systems is down, and you then issue a
STOP RDF command on the network master’s primary system, the STOP RDF
command could appear to hang. The reason for this is that the RDFNET process
might be trying to open a file for the system whose path is down. In such a case, the
RDFNET process waits until either the line comes back up or the Expand level-4 timer
expires. If the RDFNET process must wait for the the Expand level-4 timer to expire, it
will not be able to respond to the STOP RDF or abort RDF request until the timer
expires. By default, the timer is four or five minutes.
If you are waiting for the network master subsystem to shut down, and the operation
does not appear to be happening, check the communication lines to the other systems
in the network. If one of them is down and the RDFNET process is tying up the orderly
shutdown of RDF, stop the RDFNET process manually.
RDF Networks and Stop-Update-to-Time
Operations
Stop-update-to-time operations affect only the backup database of the particular
system on which they are initiated. If you have an RDF network, you can execute a
stop-update-to-time operation on any primary system in the network, but the operation
affects only the backup database of the system on which it is initiated (it does not affect
data in any other backup database, even for network transactions).
For example, suppose you have ten RDF subsystems in your RDF network, and most
transactions on each system touch two or more systems in the network. Thus, nearly
every transaction is a network transaction. If you execute a stop-update-to-time
operation on one of these systems, that operation only brings that particular
subsystem’s backup database into a consistent state with regard to transaction commit
times on the associated primary database. It does not execute undo operations on any
other backup systems in the RDF network.
To illustrate this, assume you began a transaction (T
10
) at 12:00 P.M., executed ten
updates on each of two primary systems in an RDF network (\A and \B), and
Caution. If you stop any RDF subsystem in an RDF network, you could lose large amounts of
committed data in the event of an unplanned outage.