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
Zero Lost Transactions (ZLT)
HP NonStop RDF System Management Manual—524388-003
16-5
Using CommitHoldMode
all of the audit records that were generated on the primary system prior to the system
failure, and no committed data is lost.
If you lose the primary system to a disaster and that disaster does not affect the
standby and backup systems, no committed transactions are lost because RDF on
the backup system can fetch all missing audit records from the remote mirrors. If a
regional disaster takes down both the primary and the standby systems, however, you
can still resume business on the backup system but without the ZLT guarantee (some
transactions committed on the primary system may be lost).
Using CommitHoldMode
Starting with the G06.26 release version update (RVU), the HP NonStop TMF product
includes the CommitHoldMode mode.
If you want ZLT protection, you must configure your audit trails with the
COMMITHOLDMODE attribute set to on. Doing so causes each write to the audit trail
to be directed to the remote audit-trail disk first. If that write fails for any reason, TMF
activates commit-hold mode.
If CommitHoldMode mode is activated, TMF stops all further commit operations.
Because transactions on the primary system cannot commit or abort while the remote
mirror is unavailable, you achieve ZLT protection if you should lose your primary
system while commit-hold mode is activated. However, when such an event occurs,
transaction processing on the primary system effectively stops.
TMF provides another configuration attribute associated with CommitHoldMode:
COMMITHOLDTIMER. If CommitHoldMode is activated, the COMMITHOLDTIMER
value specifies how long you want CommitHoldMode to remain activated and what to
do when that time is reached. The parameters are as follows:
COMMITHOLDTIMER {timeout [ON TIMEOUT {SUSPEND|CRASH}] | -1 }
If timeout is set to a positive value (from 5 seconds to 24 hours) and
CommitHoldMode becomes activated, all commit processing stops until either you
correct the issue causing the activation or the timeout value is reached. If the timeout
value is reached, TMF performs the action specified by the ON TIMEOUT option
(SUSPEND or CRASH).
CommitHoldMode affects transaction processing on your primary system dramatically
when a remote mirror becomes unavailable. If a remote mirror becomes unavailable,
you must choose whether you need ZLT protection or the resumption of transaction
processing.
Note. You must connect the remote mirrors to the standby system before starting the RDF
takeover operation; otherwise, the takeover aborts because RDF cannot find the disks you
configured in RDF for remote mirroring. In such a case, you should connect the disks and then
restart the RDF takeover operation.