RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

T13 preceded the commit for T12. Therefore, the purger determines that these two transactions
could not have touched the same data, and T13 does not need to be undone.
This illustrates a very important point. With network transactions, the commit sequence of
network transactions might differ from one node to another, depending on where the transactions
originated. For example, consider two network transactions: T101 and T102. Assume T101
originated on \M and T102 originated on \N. Assume further that they altered data on both \M
and \N, and committed at the same time. The commit operation for T101 is coordinated by the
TMP on \M because that is where T101 originated; similarly, T102 is coordinated by the TMP
on \N because 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 271).
(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.
302 Network Transactions