RDF System Management Manual
Table Of Contents
- RDF System Management Manual
- What’s New in This Manual
- About This Manual
- 1 Introducing RDF
- RDF Subsystem Overview
- RDF Processes
- RDF Operations
- Reciprocal and Chain Replication
- Available Types of Replication to Multiple Backup Systems
- Triple Contingency
- Loopback Configuration (Single System)
- Online Product Initialization
- Online Database Synchronization
- Online Dumps
- Subvolume- and File-Level Replication
- Shared Access DDL Operations
- EMS Support
- SMF Support
- RTD Warning Thresholds
- Process-Lockstep Operation
- Support for Network Transactions
- RDF and NonStop SQL/MX
- Zero Lost Transactions (ZLT)
- Monitoring RDF Entities With ASAP
- 2 Preparing the RDF Environment
- 3 Installing and Configuring RDF
- 4 Operating and Monitoring RDF
- 5 Managing RDF
- Recovering From File System Errors
- Handling Disk Space Problems
- Responding to Operational Failures
- Stopping RDF
- Restarting RDF
- Carrying Out a Planned Switchover
- Takeover Operations
- Reading the Backup Database
- Access to Backup Databases in a Consistent State
- RDF and NonStop SQL/MP DDL Operations
- RDF and NonStop SQL/MX Operations
- Backing Up Image Trail Files
- Making Online Dumps With Updaters Running
- Doing FUP RELOAD Operations With Updaters Running
- Exception File Optimization
- Switching Disks on Updater UPDATEVOLUMES
- 6 Maintaining the Databases
- 7 Online Database Synchronization
- 8 Entering RDFCOM Commands
- 9 Entering RDFSCAN Commands
- 10 Triple Contingency
- 11 Subvolume- and File-Level Replication
- 12 Auxiliary Audit Trails
- 13 Network Transactions
- Configuration Changes
- RDF Network Control Files
- Normal RDF Processing Within a Network Environment
- RDF Takeovers Within a Network Environment
- Takeover Phase 1 – Local Undo
- Takeover Phase 2 – File Undo
- Takeover Phase 3 – Network Undo
- Takeover Phase 3 Performance
- Communication Failures During Phase 3 Takeover Processing
- Takeover Delays and Purger Restarts
- Takeover Restartability
- Takeover and File Recovery
- The Effects of Undoing Network Transactions
- Takeover and the RETAINCOUNT Value
- Network Configurations and Shared Access NonStop SQL/MP DDL Operations
- Network Validation and Considerations
- RDF Re-Initialization in a Network Environment
- RDF Networks and ABORT or STOP RDF Operations
- RDF Networks and Stop-Update-to-Time Operations
- Sample Configurations
- RDFCOM STATUS Display
- 14 Process-Lockstep Operation
- Starting a Lockstep Operation
- The DoLockstep Procedure
- The Lockstep Transaction
- RDF Lockstep File
- Multiple Concurrent Lockstep Operations
- The Lockstep Gateway Process
- Disabling Lockstep
- Reenabling Lockstep
- Lockstep Performance Ramifications
- Lockstep and Auxiliary Audit Trails
- Lockstep and Network Transactions
- Lockstep Operation Event Messages
- 15 NonStop SQL/MX and RDF
- Including and Excluding SQL/MX Objects
- Obtaining ANSI Object Names From Updater Event Messages
- Creating NonStop SQL/MX Primary and Backup Databases from Scratch
- Creating a NonStop SQL/MX Backup Database From an Existing Primary Database
- Online Database Synchronization With NonStop SQL/MX Objects
- Offline Synchronization for a Single Partition
- Online Synchronization for a Single Partition
- Correcting Incorrect NonStop SQL/MX Name Mapping
- Consideration for Creating Backup Tables
- Restoring to a Specific Location
- Comparing NonStop SQL/MX Tables
- 16 Zero Lost Transactions (ZLT)
- A RDF Command Summary
- B Additional Reference Information
- C Messages
- D Operational Limits
- E Using ASAP
- Index
Network Transactions
HP NonStop RDF System Management Manual—524388-003
13-11
The Effects of Undoing Network Transactions
Assume that the primary system \B goes down after having transmitted the commit
record for T
13
to its backup system \Y. At that point \Y has the commits for T
10,
T
13,
T
20
, T
21
, T
22
and T
36
. \Y only has to perform local undo (during which T
12
is undone).
The purger on \X (the network master) determines that the first transaction requiring
network undo is T
12
because that transaction was active on both \A and \B when \B
went down. Therefore, even though T
12
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. Note
that 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 T
12
, transactions T
14
and T
15
must also be undone on \X because
they followed the commit of T
12
on \A and their database changes could have been
based on the committed outcome of T
12
. If T
14
and T
15
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. Note that T
14
is a local transaction, not a
network transaction. Nonetheless, its database changes could have been based on
the outcome of T
12
and therefore must be undone. Thus, both network and business
consistency are maintained.
T
13
does not, however, have to be undone even though it committed on \A after T
12
.
Why? Because the purger on \X (the network master) determines that, although T
13
followed T
12
on \A, the sequence for these two commits had to have been reversed on
\B, where the commit for T
13
preceded the commit for T
12
. Therefore, the purger
determines that these two transactions could not have touched the same data, and T
13
does not need to be undone.
This illustrates a very important point. With network transactions, the commit
sequence of network transactions may differ from one node to another, depending on
where the transactions originated. For example, consider two network transactions:
T
101
and T
102
. Assume T
101
originated on \M and T
102
originated on \N. Assume
further that they altered data on both \M and \N, and committed at the same time. The
commit operation for T
101
is coordinated by the TMP on \M because that is where T
101
originated; similarly, T
102
is coordinated by the TMP on \N because that is where T
102
originated. Thus, on \M, the sequence of commit records on the audit trail will likely be
T
101
followed by T
102
, whereas on \N it will likely be T
102
followed by T
101
.
Note, for the following two reasons, that we can be certain T
101
and T
102
did not alter
the same data:
1. Transaction record locking would have prevented these transactions from altering
the same data.
2. The commit sequence on \M being T
101
followed by T
102
and the commit
sequence on \N being T
102
followed by T
101
unequivocably 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.