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
Triple Contingency
HP NonStop RDF System Management Manual—524388-003
10-4
The RETAINCOUNT Configuration Parameter
The RETAINCOUNT Configuration Parameter
The purger RETAINCOUNT parameter specifies how many image trail files (including
the one currently in use) must be retained on disk for each image trail. The default
value for this parameter is two.
The importance of this parameter is as follows. If you lose the primary system, the
triple contingency protocol will work only if one of the backup systems has retained all
of the audit information that the other is missing.
For example, assume that you have lost the original primary system (\A), you have
successfully completed a takeover on both backup systems (\B and \C), and the
MAT positions displayed by the respective 735 messages are as follows:
\B: 735 LAST MAT POSITION: Sno 10, Rba 100500000
\C: 735 LAST MAT POSITION: Sno 10, Rba 100000000
500 kilobytes of audit information is missing on \C.
Suppose that the image trail files are relatively small, such that the audit record at MAT
10, 100000010 was placed at the start of image trail file AA000025 on \B. If the purger
on \B is allowed to purge AA000025 before the takeovers occur, the triple contingency
protocol will fail because \C is missing some of the purged audit information (Sno 10,
Rba 100000010 through Sno 10, Rba 100500000).
The RETAINCOUNT parameter is designed to prevent such a situation, although it is
up to you to set this value correctly.
You must determine how much time disparity to allow for in the event that one receiver
falls behind the other. Such a disparity would occur, for example, if the
communications lines between the primary system and one of the backup systems
were to go down for some period of time. The RETAINCOUNT parameter must be
such that no image trail files that might be needed for triple contingency are ever
purged.
The best way to do determine the appropriate RETAINCOUNT value is to pick an
acceptable time differential such as 24 hours, 36 hours, or 48 hours, determine how
many image trail rollovers typically occur within that amount of time, and then set the
RETAINCOUNT parameter to that number of files.
For example, if you believe the two receiver processes will never be more than 36
hours apart in their RDF processing and your image trail file sizes are such that
rollovers occur only once every 24 hours, then you would be safe specifying a
RETAINCOUNT of three for both backup systems. In that situation, the purger process
on both backup systems will always keep at least three image trail files on disk (the
one the receiver is currently writing to and the previous two). Assume, on the backup
system which is further ahead in its RDF processing, that files AA000010, AA000011,
and AA000012 are on disk, the receiver rolls over to file AA000013, and all updaters
have just begun reading file AA000013. Files AA000010 through AA000012 might be
considered expendable (and therefore be eligible for purging), but, because the