More specifically, assume that system \A (the network master) executes:
1.
T10 (network transaction started on \A)
2.
T11 (non-network transaction)
3.
T11 commit
4.
T10 commit
5.
T12 (network transaction started on \A)
6.
T12 commit
7.
T13 (network transaction started on \B)
8.
T13 commit
9.
T14 (non-network transaction)
10.
T15 (network transaction started on \A)
11.
T14 commit
12.
T15 commit
At approximately the same time system \B executes:
1.
T10 (network transaction started on \A)
2.
T20 (non-network transaction)
3.
T12 (network transaction started on \A)
4.
T13 (network transaction started on \B)
5.
T21 (non-network transaction)
6.
T22 (non-network transaction)
7.
T36 (network transaction started on \C)
8.
T21 commit
9.
T22 commit
10.
T36 commit
11.
T20 commit
12.
T10 commit
13.
T13 commit
14.
T12 commit
Assume that the primary system \B goes down after having transmitted the commit record for
T13 to its backup system \Y. At that point \Y has the commits for T10, T13, T20, T21, T22 and
T36. \Y only has to perform local undo (during which T12 is undone).
The purger on \X (the network master) determines that the first transaction requiring network
undo is T12 because that transaction was active on both \A and \B when \B went down.
Therefore, even though T12 originated on \A and was committed on \A, it must be undone on
\X (the backup system of \A) because it was undone on \Y (the backup system of \B). This
ensures database consistency across both nodes. When the purger identifies the first network
transaction that must be undone during network undo processing, it logs an RDF 877 event
message specifying that transaction.
Besides transaction T12, transactions T14 and T15 must also be undone on \X because they
followed the commit of T12 on \A and their database changes could have been based on the
committed outcome of T12. If T14 and T15 are not also undone, database consistency could be
compromised because their effects on the database might have been based upon data that was
backed out. T14 is a local transaction, not a network transaction. Nonetheless, its database changes
could have been based on the outcome of T12 and therefore must be undone. Thus, both network
and business consistency are maintained.
T13 does not, however, have to be undone even though it committed on \A after T12. Why?
Because the purger on \X (the network master) determines that, although T13 followed T12 on
\A, the sequence for these two commits had to have been reversed on \B, where the commit for
RDF Takeovers Within a Network Environment
301
Содержание 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: ......