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

that is where T102 originated. Thus, on \M, the sequence of commit records on the audit trail will
likely be T101 followed by T102, whereas on \N it will likely be T102 followed by T101.
For these two reasons, we can be certain T101 and T102 did not alter the same data:
• Transaction record locking would have prevented these transactions from altering the same
data.
• The commit sequence on \M being T101 followed by T102 and the commit sequence on \N
being T102 followed by T101 unequivocally means that these two transactions were active
at the same time and committed at the same time. Therefore they could not have altered the
same data.
If we return to the issue of T13 in the example further above, the commit sequence differs on \A
and \B. When the purger on \A determines that T12, T14, and T15 must be undone, it also
determines that the results of T13 can be kept intact because T13 had to have completed on \B
before T12. Why? The commit records on \A guarantee that both T12 and T13 did indeed commit.
Therefore, although the commit record for T12 is missing from \B, the commit record for T13 is
present. This guarantees that T13 committed prior to T12, and that the results of T13 can be kept
intact on both nodes.
When a purger determines that it can keep the results of a transaction even though that transaction
follows one that must be undone because data for it is missing elsewhere, the purger logs an RDF
823 event message identifying the particular transaction.
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 260). (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.
286 Network Transactions