RDF/IMP and IMPX System Management Manual (RDF 1.4+)

Network Transactions
HP NonStop RDF/IMP and IMPX System Management Manual—524388-001
13-5
RDF Network Control Files
RDF Network Control Files
The following control files exist in the Master Image Trail (MIT) subvolume of all RDF
subsystems that are configured for replication of network transactions: ZRDFLCMT,
ZRDFLCM2, and ZNETUNDO. Additionally, the network master has three more files:
ZRDFNMTX, ZRDFNMT2, ZRDFNMT3. These files contain internal information that
RDF needs to correctly execute takeover operations involving an RDF network. The
files are empty until you actually initiate a takeover operation on a backup system
within an RDF network.
Normal RDF Processing Within a Network
Environment
Each RDF subsystem within an RDF network conducts its processing individually, as
though it were not involved in an RDF network. That is, for a given RDF subsystem,
the extractors read the MAT and auxiliary audit trails and send data to the receivers.
The updaters read their data from their image trails and apply it to their
UpdateVolumes. During normal processing, no RDF subsystem (except the RDFNET
process within the network master primary system) interacts with any other RDF
subsystem in the RDF network. Therefore, the performance of an individual RDF
subsystem is unaffected by its inclusion within an RDF network.
RDF Takeovers Within a Network Environment
If you have configured an RDF network and must initiate a takeover on a backup
system in the network, then you must execute a takeover on all the backup systems in
the network. You do that by issuing an RDFCOM TAKEOVER command on each
individual backup system. When a takeover occurs within an RDF network, each
subsystem’s takeover operation consists of three phases of operation:
1. A local undo phase
2. A file undo phase
3. A network undo phase
Takeover Phase 1 – Local Undo
This phase is identical to a normal RDF takeover (one that is totally unrelated to an
RDF network). It consists of determining what transaction data has already been
applied to the backup database but whose outcomes are unknown. Once the
transactions have been identified, all updates associated with them are undone. The
purger process determines what transactions must be undone and it writes the list into
the ZTXUNDO file in the MIT.
For example, suppose you began a transaction on your primary system, you executed
ten updates, and you committed the transaction, but the extractor process was only