RDF/IMP, IMPX, and ZLT System Management Manual

Managing RDF
HP NonStop RDF/IMP, IMPX, and ZLT System Management Manual—524388-002
5-6
Communications Line Failures
•
TMF subsystem crash after which the TMF volume recovery is successful
•
TMF file recovery operation that is not to a timestamp
RDF cannot recover from the following events:
•
TMF file recovery operation to a timestamp
•
TMF subsystem crash after which TMF cannot perform a successful volume
recovery operation
•
Double system failure (the backup system fails after an RDF takeover), if you are
not using the triple contingency feature
After a TMF file recovery to a timestamp or to first purge, or after a TMF subsystem
crash for which volume recovery cannot succeed, the databases or the affected files
on the primary and backup systems must be resynchronized.
If the primary system fails, you might want to request a takeover operation to switch
application processing to the backup system.
Communications Line Failures
RDF can recover from communications line failures. When the extractor detects that
the communications lines to the backup system are down, it reports the error to the
EMS event log. The extractor attempts to resend data every minute until the lines to
the backup system are reenabled.
If you stop RDF on the primary system when the communications lines to the backup
system are down, the monitor tries to send a stop message to the processes on the
backup system and reports that the lines are down. All of the processes on the backup
system continue to run until a STOP RDF command is issued at the backup system.
Processor Failures
All RDF processes other than RDFCOM run as process pairs. If a CPU failure causes
a primary RDF process to fail, the backup process takes over without interruption in
service.
Note. If you issue a STOP RDF command on the primary or backup system while the network
is down, you must also issue a STOP RDF command on the other system while the network is
still down.