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
Preparing the RDF Environment
HP NonStop RDF System Management Manual—524388-003
2-13
Configuring an SMF Environment on the Backup
RDF System
•
Place the SMF catalog in the default SMF catalog subvolume on a volume that is
protected by RDF.
The extractor automatically filters out changes to the SMF catalog if the catalog is
in the default SMF catalog subvolume. If you store the catalog in your own
subvolume, the extractor will try to replicate changes to the catalog, which could
have an adverse affect on RDF and any SMF catalogs with the same subvolume
name on the backup system.
•
Place the SMF catalog in a subvolume that is explicitly excluded from RDF
protection (the INCLUDE and EXCLUDE clauses are described in Section 11,
Subvolume- and File-Level Replication).
Configuring an SMF Environment on the Backup RDF System
RDF supports the replication to SMF logical volumes on the backup system, with the
following restrictions:
1. When replicating to an SMF logical volume, the logical volume must belong to an
SMF pool that contains 15 or fewer physical volumes, hence each updater can
apply audit to up to 15 physical disks.
2. The RDF/IMP product limits the total number of physical or virtual UPDATE
volumes to 255. RDF/IMPX and ZLT have no such limitation, other than the limit of
255 updaters and each updater only being able to work on a maximum of 15
physical volumes.
3. Image trail volumes cannot reside on SMF logical volumes.
There are no restrictions on the placement of SMF catalog files on the backup system.
If the backup system could ever become a primary (such as after an RDF takeover, for
example, or as the result of a planned switchover), then the restrictions described in
the preceding topic for primary systems also apply.
RDF replicates Enscribe file creations when audited Enscribe files are created on RDF
protected volumes. When the UPDATEVOLUME is a virtual disk, the updater process
tells SMF to create the file and register it in the SMF catalog. When the
UPDATEVOLUME is a virtual disk comprised of multiple physical disks, SMF decides
which physical disk will store the file. You have no control over where a new Enscribe
file is created. Refer to the HP NonStop Storage Management Foundation (SMF)
Management Manual for further information about the factors SMF uses to decide on
the file placement.
Note. A single updater process only works on 500 files at any time. If you have a virtual disk
that has many physical disks in its pool, and if the number of files that need to be updated by
the updater assigned to that virtual disk exceeds 500, the updater will close some files in order
to work on files it does not already have open. If this updater must regularly work on more than
500 files, the performance of the updater is impacted. For optimal updater performance,
ensure that no single updater must work on more than 500 files on a regular basis. This
condition might mean that you have to reduce the number of physical disks in a pool.