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
HP NonStop RDF System Management Manual—524388-003
14-1
14 Process-Lockstep Operation
The RDF/IMPX and RDF/ZLT products include the process-lockstep operation, which
is process-based. That is, when a process invokes the lockstep operation for a
business transaction, the process must wait until all audit records associated with that
business transaction are safely stored in image trails on the backup system before
continuing.
Note that process-lockstep is not needed with RDF/ZLT because ZLT functionality
provides means whereby no committed data is ever lost during an unplanned outage.
Hence, ZLT functionality is a more efficient means of achieving the same result as
process-lockstep. Process-lockstep can be used with RDF/ZLT, but does not add
anything that ZLT functionality does not already provide.
A lockstep operation consists of the following steps.
1. A process starts a business transaction and does database updates.
2. The process calls endtransaction to commit the work.
3. The process issues a DoLockstep procedure call.
4. The DoLockstep procedure communicates with an RDF gateway process.
5. The gateway starts a lockstep transaction against an RDF lockstep file.
6. The gateway communicates with the RDF subsystem regarding the lockstep
transaction.
7. The RDF subsystem tells the gateway when lockstep audit has been safely stored
on the backup system.
8. The gateway returns status to the DoLockstep procedure.
9. DoLockstep returns status to the process.
Thus, although the business transaction is actually committed on the primary system
(and the file locks or table locks are released), the process cannot continue processing
until all of the audit data associated with that transaction is safely stored in the image
trails on the backup system).
While the process waits until DoLockstep completes, other processes can view and
modify the just-changed records, and this must be understood and taken into
consideration by the application designer.
Note. The lockstep capability can be used only for replicating Master Audit Trail (MAT) data.
In addition, the lockstep capability cannot be used in an RDF network environment.
Furthermore, you can have only one RDF subsystem configured for lockstep on a given node
because the gateway can only be configured to a single extractor process.