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
Entering RDFCOM Commands
HP NonStop RDF System Management Manual—524388-003
8-45
Command Overview
•
If you plan to include the TIMESTAMP option in the INITIALIZE RDF command,
make sure that the primary system database is backed up after the TMF shutdown
so that the backup database can be restored at this point in the audit trail.
Consider the following example:
a. TMF and RDF subsystems are running.
b. TMF subsystem is stopped, and RDF subsystem subsequently stops.
c. TMF subsystem is started and application processing resumed.
d. TMF subsystem is stopped.
If you initialize RDF at the shutdown point at Step d, you should restore on the
backup system a copy of the primary system database taken at Step d. The
databases would not be synchronized if the database at Step b was restored to the
backup system.
If you initialize RDF to the timestamp corresponding to Step b, you should restore
on the backup system a copy of the primary system database taken at Step b.
•
Initialize RDF at the most recent TMF shutdown point. If you initialize RDF at an
earlier shutdown point, RDF operations will start at that point but will shut down
when the next TMF shutdown point is reached. In this case, you must restart RDF
quickly so that operations on the backup system do not fall behind those on the
primary system. If you choose to initialize RDF at a TMF shutdown point that is not
the most recent, watch the RDF event messages for the RDF shutdown message
and then restart RDF immediately.
•
If you include the TIMESTAMP option in the INITIALIZE RDF command, use the
following guidelines to determine when you must restore the backup database:
•
If you are going to start RDF with UPDATE ON, restore the database to the
backup system before you start RDF.
•
If you are going to start RDF with UPDATE OFF, you do not have to restore the
database. However, if the need for an RDF takeover arises, you must then
restore the database on the backup system before you issue the TAKEOVER
command.
•
If you include the TIMESTAMP, INITTIME, or SYNCHDBTIME options in the
INITIALIZE RDF command, it is suggested that all MAT files are present from the
current file to the file containing the TMF shutdown record or the commit/abort
record with a timestamp less than the specified timestamp. If RDFCOM tries to
open a nonexistent file, RDFCOM can trigger restoration of the missing audit trail
files from tape or disk based on your response to a prompt message. Therefore,
not every file in the MAT must be present, from the initial file to the current file. For
example, if the current file is AA000010 and the shutdown record is in AA000009,
only files AA000009 and AA000010 need be present.
•
In any event, if you plan to enable updating on the backup system as part of the
new configuration, ensure that the primary and backup databases are logically