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
Introducing RDF
HP NonStop RDF System Management Manual—524388-003
1-19
Receiver Process
by the extractor, you will have to reinitialize RDF and resynchronize the primary and
backup databases.
In response to the UNPINAUDIT command, RDFCOM issues a prompt asking you to
confirm your request.
If the files are unpinned successfully, RDFCOM issues an informational message to
that effect.
If an error occurs while attempting to unpin the audit trail files, the command is ignored,
and RDFCOM issues a message indicating the error.
Receiver Process
A receiver process is a process pair that runs on the backup system. There is one
receiver for each configured extractor. A receiver process accepts audit records from
its extractor, sorts them, and then writes them to the appropriate RDF image trail, as
shown in Figure 1-6. (The restartability of a receiver ensures the receiver's correctness
at process takeover or under any conditions requiring resynchronization with its
extractor.)
A receiver determines which updater will apply the data, and sorts the data into the
image trail used by that updater. The records in the image trails are subsequently used
by updater processes to update the backup database.
Each receiver also creates image trail files, preallocates extents, and initiates rollovers.
Sorted Image Trails
RDF maintains its image data on disk volumes specified during RDF configuration. On
each of these volumes, the collection of files that contains image data is known as an
image trail; that is, there is one image trail per individual image trail volume.
The standard image trail used by RDF, called the master image trail, contains the
transaction status records that hold key information about whether a transaction has
committed or aborted. The master image trail is stored on the disk volume selected by
the master receiver’s RDFVOLUME configuration option. Note that you cannot
configure any updaters to the master image trail.
All updaters must be configured to secondary image trails. You can configure up to 255
secondary image trails in addition to the master image trail. Each secondary image trail
is stored on a separate volume, selected through the IMAGETRAIL configuration
option.
RDF uses multiple sorted image trails. With this feature, the receiver detects which
updaters are associated with which image trails. When it receives a record, the
receiver identifies the updater that will apply the record to the backup database. The
receiver then sorts the record into the appropriate image trail, and the record is written
to that image trail.