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
Managing RDF
HP NonStop RDF System Management Manual—524388-003
5-24
Takeover Failure
For RDF network takeover considerations, see Section 13, Network Transactions.
For super fast takeover, see Tips for Executing Fast Business Takeover Operations in
section 1.
Takeover Failure
If a double CPU failure occurs and the receiver process pair or an updater process pair
fails during a takeover operation, you can resume the operation just by entering the
TAKEOVER command through RDFCOM again. You can ascertain that a takeover
operation failed by issuing a STATUS RDF command and getting a response such as
the following:
STATUS RDF (\RDF04 -> \RDF05) is NOT running
A partial RDF TAKEOVER has completed
Also, a takeover failure generates a 725 event in the EMS log.
Monitor Considerations
Whether the RDF monitor was started when the initial TAKEOVER command was
executed or not, this process is always started when the TAKEOVER command is
reissued.
Updater Considerations
When the purger shuts down at the end of the takeover operation, it examines the
context record of each updater process to determine if that updater has processed all
applicable audit data through the end-of-file in the image trail. If all updaters have
processed through the end-of-file, the purger logs a 724 message to the EMS event
log, indicating that the takeover operation completed successfully. But if it determines
that one or more updaters have terminated prematurely, the purger logs RDF Message
726 for each updater that failed and then logs RDF Message 725, a general message
indicating that the takeover operation did not complete successfully. If these messages
appear in the EMS event log, you must reissue the TAKEOVER command.
Takeover and File Recovery
After you initiate a takeover, it is possible that the last committed transactions did not
make it to the backup system (meaning that the backup and primary databases are not
synchronized).
If the takeover completes on the backup system, the purger logs an RDF event 888
specifying a MAT position (sno, rba). Subsequently, when the primary system is once
again online and you are ready to switch the applications back to the primary, you first
initiate a TMF file recovery command with the TOMATPOSITION option on the primary
system specifying the logged MAT position from the 888 event. TMF restores the