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
Installing and Configuring RDF
HP NonStop RDF System Management Manual—524388-003
3-26
Configuring RDF
OWNER Parameter
The OWNER parameter specifies a userid under which all RDF processes will always
run. This global configuration parameter provides functionality whereby any super-
user group userid can start and stop RDF.
To illustrate this functionality, imagine ten users are responsible for managing a
particular RDF configuration and that SUPER.RDF is configured as the OWNER.
Instead of providing all ten users access to the SUPER.RDF userid, each individual
user can be assigned a separate super-user group userid. If one user is assigned
SUPER.FIRST and another SUPER.SECOND, for example, they can both log on with
their userid and be able to start or stop RDF. The RDF processes do not run under
SUPER.FIRST or SUPER.SECOND, however, but under SUPER.RDF (the RDF
OWNER assigned during configuration). The same principal applies to the other eight
users.
The userid associated with OWNER must be a valid Guardian userid and must identify
an existing user account on the RDF primary and backup systems. The OWNER must
also be a member of the super-user group, since that is an existing requirement in
RDF for stopping and starting RDF.
OWNER is an unalterable value. There is no need to change the value, unless you
configured it incorrectly (in which case you must reinitialize RDF with the correct
value).
If the OWNER parameter is omitted, only the userid that initializes RDF can start or
stop RDF (as is true for all versions of RDF prior to 1.7).
Setting Image Trail Parameters
Use SET IMAGETRAIL and ADD IMAGETRAIL commands to configure the following
image trail parameter:
•
ATINDEX
The ATINDEX parameter associates an image trail with a specific audit trail on the
primary system.
The RECEIVER RDFVOLUME parameter specifies the disk volume that contains the
receiver’s master image trail. The receiver process writes all commit/abort records to
this volume. All updaters must be configured to secondary image trails.
To create secondary image trails, use the ADD IMAGETRAIL command. Later, when
you configure your individual updater processes, you assign each of these processes
to a specific image trail. By spreading updaters across secondary image trails, you
reduce the number of updaters contending for a specific trail. ATINDEX specifies which
receiver will write to that trail; 0 is the default.