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
Auxiliary Audit Trails
HP NonStop RDF System Management Manual—524388-003
12-4
Takeover Ramifications
Takeover Ramifications
If an auxiliary extractor is running behind the master extractor when you issue a
TAKEOVER command, a transaction just committed on the primary system (and who’s
commit record was received by the master receiver) could be backed out on the
backup system.
This could happen under the following circumstances:
•
In addition to the MAT, you have configured RDF to protect one or more auxiliary
audit trails.
•
When the primary system fails, an auxiliary extractor is running behind the master
extractor. For example, the master receiver has received the commit record
associated with a particular transaction, but the auxiliary receiver is missing audit
data for that same transaction.
•
A committed transaction (whose commit record was received by the master
receiver just before the primary system failure) updated only a volume associated
with the MAT.
Usage of Master and Auxiliary Audit Trails
A master extractor must always be associated with the MAT even if no data volumes
are configured to the MAT. A master extractor is required because the MAT contains
audit records that preserve TMF control information required by RDF on the backup
system, and this control information is not stored in any auxiliary audit trail.
Using Expand Multi-CPU Paths
The use of Expand with ATM or Fast Ethernet provides considerable bandwidth, and it
is often sufficient to have a single Expand path driven out of a single processor.
If your RDF configuration is replicating auxiliary audit trails, however, the total amount
of audit data to be sent from the primary system to the backup system could be more
than a single Expand path can handle. If that is the case, you should use the Expand
multi-CPU path feature.
Expand multi-CPU paths enable you to spread the communications load over multiple
processors by connecting multiple Expand line-handler processes, each in a separate
processor, between two adjacent nodes. In an RDF environment, you would use this
feature to establish dedicated paths for the master extractor-receiver pair and multiple
auxiliary extractor-receiver pairs.
Suppose you will be configuring three extractor-receiver pairs: one for the MAT and
one each for auxiliary audit trails AUX01 and AUX02. Suppose further that both your
primary and backup systems have ten processors. For each Expand multi-CPU path,
you place the matching Expand line-handlers in the same processor on both systems.