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
Online Database Synchronization
HP NonStop RDF System Management Manual—524388-003
7-17
Partial Database Synchronization Issues
Described below is a set of steps that can be used to synchronize individual partitions
of NonStop SQL/MP tables (either primary or secondary partitions).
Requirements for Synchronization of Individual Partitions
The following methods work only if all the partitions of a given table still reside on disk
on the backup system. If you do not have all partitions of a given table backed up on
tape and you encounter a total media failure that destroys or renders a volume
inoperable on your backup system, then you might have to synchronize your entire
table.
To prevent this you should take the precaution of having all tables backed up in their
entirety on tape. With the protocol for synchronizing individual tables below, however,
this does not mean you have to back up all tables on your backup system with all
current data. Rather, you can use the following method, which will be very fast and will
enable fast resynchronization should you ever encounter a complete media failure that
requires resynchronization of individual partitions of a table.
1. Rename the table to a temporary name using the SQLCI ALTER TABLE
command.
2. Create a duplicate table with the original name of the table you renamed in step 1.
This table must have all the same partitions as the original table.
3. Use BACKUP to put the duplicate table on tape. It will have all the partitions, but
they are empty. Thus, it will not take long to back the partitions up, nor will it take
long to restore any of the partitions.
4. Rename the table to a temporary name and then drop it. By renaming it before
dropping it, you preserve any indexes that are associated with the original table
name.
5. Rename the temporary table (step 1) back to the original table name.
Thus, you now have on tape empty partitions for the entire table. Should you ever
lose a volume to a complete media failure, you can install a new disk and then use the
RESTORE utility with the PARTONLY option to recover the missing partition. Note
that because you have backed up a table with the name you need on the backup
system, you can restore any partition that you need to with the PARTONLY option and
without having to use the MAP NAMES option. Once you have restored the empty
partition, you can use the protocol described below to synchronize the affected
partition.
Note that there is no recovery for a media failure that wipes out an individual partition
of a partitioned index. If that happens, you will need to drop the index from the
associated table, thereby eliminating all other partitions of the index. Then you must
create a new index.