14 Network Transactions
The RDF/IMPX and RDF/ZLT products are able to guarantee backup database consistency for
transactions that update data residing on more than one RDF primary system. RDF/IMPX and
RDF/ZLT can map the volumes being protected to both the MAT and auxiliary audit trails.
NOTE:
Network transaction processing is currently not supported in configurations that use
the triple contingency feature. You must use RDF/IMPX or RDF/ZLT to protect all databases
open to network transactions.
Without planning for network transaction support, the RDF product cannot guarantee database
consistency among the associated backup systems following the failure of one of the primary
systems.
Support for network transactions requires two major external changes.
1.
If you have a distributed database spread over several RDF primary systems, you must
configure an RDF network wherein each primary system residing on its own, mutually
exclusive node has its own RDF subsystem that replicates its local data to its own backup
system. This is referred to as an RDF network because each RDF subsystem knows the names
of the systems protected by all other RDF subsystems in the network. One, and only one,
RDF subsystem within the network is configured as the network master.
2.
If you lose one or more RDF primary systems in the RDF network, you must execute RDF
takeover operations on all backup systems in the network.
For those primary systems still alive, you must first quiesce all application activity (both
local and remote) so that no further database updates are being performed, and then bring
down the communication lines between the primary and backup systems before initiating
the takeover.
With network transaction support, you must now be more careful when creating Enscribe files
that have alternate key files. Specifically, when you create an Enscribe file with an altkey file you
must ensure that both files reside on the same primary system and that both are protected by
the same RDF subsystem. If you do not do so, then the updater responsible for creating the file
on the backup system will not create the file; rather, it will report an error 740 when it determines
that the altkey file is not protected by its RDF subsystem.
For RDF/ZLT configurations, all nodes that participate in a network transaction need to be
configured in the RDF network for RDF/ZLT protection.
Configuration Changes
To support network transactions, several configuration attributes and a configuration record
have been added to the RDF configuration file.
NETWORK Attribute
This attribute, located in the RDF configuration record, specifies whether or not you are
configuring an RDF network.
To set this attribute, use this RDFCOM command:
SET RDF NETWORK {ON | OFF}
When this attribute is set to OFF (the default value), RDF takeover operations execute just as
they have in the past, and database consistency is not guaranteed for transactions that spanned
more than one primary system.
When this attribute is set to ON, the RDF subsystem can guarantee backup database consistency
across multiple RDF systems configured within an RDF network.
Configuration Changes
295
Содержание NonStop RDF
Страница 68: ...68 ...
Страница 186: ...186 ...
Страница 260: ...260 ...
Страница 278: ...278 ...
Страница 284: ...284 ...
Страница 290: ...290 ...
Страница 308: ...308 ...
Страница 322: ...322 ...
Страница 336: ...336 ...
Страница 348: ...348 ...
Страница 464: ...464 ...
Страница 478: ......