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
16-1
16 Zero Lost Transactions (ZLT)
Zero Lost Transactions (ZLT), functionality that is available only with the RDF/ZLT
product, ensures that no transactions that commit on the primary system are lost on
the RDF backup system if that primary system is downed by an unplanned outage.
RDF achieves this though the use of remote mirroring for the relevant TMF audit-trail
volume(s). That is, one mirror of an audit-trail volume remains local to the primary
system, but the other mirror is located at a remote standby site.
When a primary system is downed by some unplanned outage or disaster, there may
be some audit data that the extractor on the primary system was unable to send to the
backup system before the outage. With ZLT functionality, RDF fetches all remaining
audit data from the remote mirror, thereby guaranteeing no loss of committed data
during the RDF takeover operation.
However, if a remote mirror is not available at the time of the outage, ZLT functionality
cannot be guaranteed. ZLT functionality can be guaranteed only if you enable the TMF
CommitHoldMode capability on your primary system by including the
COMMITHOLDMODE parameter in a TMFCOM ALTER AUDITTRAIL command.
When CommitHoldMode is enabled, TMF suspends all commit operations if a remote
mirror fails. For information about using the TMF CommitHoldMode capability, see the
topic Using CommitHoldMode later in this section and the HP NonStop TMF Reference
Manual for the G06.26 RVU.
If all of the remote mirrors are functioning, ZLT functionality has no impact on normal
RDF operations. If you must perform an RDF takeover operation, however, there are
additional steps involved that can lengthen the time to perform the overall operation. In
return, you get the ZLT guarantee of not losing any transactions that committed on the
primary system. When CommitHoldMode is enabled and a remote mirrors fails, all
active transactions are prevented from aborting or committing. That drammatically
impacts transaction processing on your primary system. For more about this situation,
see the topic Using CommitHoldMode later in this section.
ZLT functionality is only available on S-series or NonStop Integrity systems, although
RDF 1.7 runs correctly on K-series systems without using ZLT. As a result, RDF users
on K-series systems can upgrade to RDF 1.7, but ZLT functionality is not available to
them.