RDF System Management Manual for H-Series RVUs (RDF 1.8)

NOTE: If you have local transactions that do not touch data involved in network transaction
activity, and you do not want these local transactions undone just because data might be missing
for the network transactions during a takeover operation, you are advised to configure separate
RDF subsystems: one to protect just the data involved in network transaction activity, and the
second to protect the non-network data. Of course, both sets of data must have no dependencies
on the other.
Takeover and the RETAINCOUNT Value
In order for all systems in an RDF network to execute phase 3 takeover processing correctly, you
must ensure that all image data potentially needed for undo is available on each system. The
way to achieve that is to set the purger’s RETAINCOUNT to an acceptable value on each system.
For a complete discussion about this attribute and how it works, refer to Chapter 10 (page 255).
(The same RETAINCOUNT guidelines that apply to a triple contingency environment also apply
to an RDF network environment.)
If you have not set the RETAINCOUNT properly and image files have been purged that are
subsequently needed for phase 3 takeover processing, the takeover operations on the systems
where the image data is missing might fail. In such a case, your entire distributed database across
all RDF backup systems could be compromised with inconsistent data.
Network Configurations and Shared Access NonStop SQL/MP DDL
Operations
Under certain circumstances after a shared access NonStop SQL/MP DDL operation, takeover
network undo processing leads to an abort with database corruption.
To avoid this problem, use this protocol when performing shared access NonStop SQL/MP DDL
operations in a network environment:
1. Issue the RDFCOM STOP RDF command on the primary system where you plan to perform
the shared access NonStop SQL/MP DDL operation.
2. From TMFCOM STATUS TRANSACTIONS, collect all the network transactions that are
currently in progress.
3. Wait until all transactions observed in step 2 have completed and are no longer listed.
4. For all other primary nodes in your RDF network, run RDFCOM STATUS RDF commands.
5. When all other RDF subsystems in the RDF network list 0:00 extractor RTD times, issue the
RDFCOM START RDF command on the system where you had stopped RDF.
6. Perform your shared access NonStop SQL/MP DDL operation on your primary system.
7. Follow the normal method for replicating shared access NonStop SQL/MP DDL operations
on your backup system.
Network Validation and Considerations
A set of rules has been devised to ensure that all RDF subsystems in your configured RDF network
are consistent with each other.
1. You must validate all non network master subsystems before validating the network master’s
subsystem.
2. Because you cannot validate the network master until all non network master subsystems
have been validated, you cannot start the network master until all non network master
subsystems have been validated.
3. If you have validated a non network master, you are allowed to start that subsystem even
though the network master has not been validated.
See Appendix C (page 335) for the error messages that can occur during validation steps.
Network Configurations and Shared Access NonStop SQL/MP DDL Operations 283