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-9
Processor Failures
Receiver Failure
If the primary CPU of the receiver process fails, the receiver process in the backup
CPU takes over and resynchronizes with the extractor process. The extractor process
might have to resend audit data that was generated several seconds earlier. When the
CPU that failed comes back up, RDF switches the receiver to run on the reactivated
primary CPU.
Updater Failure
If the primary CPU of an updater process fails, the corresponding updater process in
the backup CPU takes over.
If both the primary and backup CPUs of an updater fail, RDF aborts. A subsequent
START RDF command restarts the process without requiring database resynchroniza-
tion. To support restartability, however, the updaters use a different mechanism than
the extractor or receiver: the updaters rely entirely on context saving rather than
checkpointing. For this reason, if the backup member of an updater process pair takes
over because the CPU of the primary member failed, the backup updater might have to
start at an earlier point in the image trail and require several minutes to reach the point
where the primary process was positioned when the CPU failed.
If the primary CPU of an updater process fails and then comes back up, RDF does not
switch the updater to run on the reactivated primary CPU. Instead, once the backup
updater takes over, it becomes (and remains) the new primary process. If you subse-
quently stop and then restart updating, however, the original CPU configuration for this
updater process is restored.
Purger Failure
If the primary CPU of the purger process fails, the purger process in the backup CPU
takes over, the current PURGETIME interval is aborted, and a new PURGETIME
interval is started. When the CPU that failed comes back up, RDF switches the purger
to run on the reactivated primary CPU.
If both the primary and backup CPUs of the purger process fail, RDF aborts.
RDFNET Failure
If the primary CPU of the RDFNET process fails, the RDFNET process in the backup
CPU takes over. When the CPU that failed comes back up, RDF switches the
RDFNET process to run on the reactivated primary CPU.
If both the primary and backup CPUs of the RDFNET process fail, RDF aborts.