RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

the TMF shutdown operation proceeds. The same can happen to the updaters when a
stop-update-to-time or a SQL shared access DDL operation enters the RDF subsystem, wherein the
updaters configured to an auxiliary audit trail may take a long time to shutdown if the auxiliary
extractor has fallen behind. When that extractor finally caztches up, the affected updaters are able
to shutdown.
Takeover Ramifications
For a non-RDF/ZLT congfiguration, if an auxiliary extractor is running behind the master extractor
when you issue a TAKEOVER command, a transaction just committed on the primary system (and
who’s commit record was received by the master receiver) could be backed out on the backup
system.
This could happen under these circumstances:
• In addition to the MAT, you have configured RDF to protect one or more auxiliary audit trails.
• When the primary system fails, an auxiliary extractor is running behind the master extractor.
For example, the master receiver has received the commit record associated with a particular
transaction, but the auxiliary receiver is missing audit data for that same transaction.
• A committed transaction (whose commit record was received by the master receiver just before
the primary system failure) updated only a volume associated with the MAT.
Usage of Master and Auxiliary Audit Trails
A master extractor must always be associated with the MAT even if no data volumes are configured
to the MAT. A master extractor is required because the MAT contains audit records that preserve
TMF control information required by RDF on the backup system, and this control information is not
stored in any auxiliary audit trail.
Using Expand Multi-CPU Paths
The use of Expand with ATM, Fast Ethernet, or Servenet provides considerable bandwidth, and it
is often sufficient to have a single Expand path driven out of a single processor.
If your RDF configuration is replicating auxiliary audit trails, however, the total amount of audit
data to be sent from the primary system to the backup system could be more than a single Expand
path can handle. If that is the case, you should use the Expand multi-CPU path feature.
Expand multi-CPU paths enable you to spread the communications load over multiple processors
by connecting multiple Expand line-handler processes, each in a separate processor, between two
adjacent nodes. In an RDF environment, you would use this feature to establish dedicated paths
for the master extractor-receiver pair and multiple auxiliary extractor-receiver pairs.
Suppose you will be configuring three extractor-receiver pairs: one for the MAT and one each for
auxiliary audit trails AUX01 and AUX02. Suppose further that both your primary and backup
systems have ten processors. For each Expand multi-CPU path, you place the matching Expand
line-handlers in the same processor on both systems.
To set up our three paths in processors 3, 5, and 7, for example, you would put matching Expand
line-handlers in processor 3 on both systems, in processor 5 on both systems, and in processor 7
on both systems. Within RDF you would then configure processor 3 as the primary CPU for the
master extractor and receiver, processor 5 as the primary CPU for the AUX01 extractor and
receiver, and processor 7 as the primary CPU for the AUX02 extractor and receiver. Thereafter
all messages between the master extractor and receiver will go through the path in processor 3
on both systems, all messages between the AUX01 extractor and receiver will go through the path
in processor 5 on both systems, and all messages between the AUX02 extractor and receiver will
go through the path in processor 7 on both systems.
For more information about Expand multi-CPU paths, see the Expand Configuration and
Management Manual.
278 Auxiliary Audit Trails