RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

6. If the duplicate tables and files were created on the primary system in step 4, use
BACKUP/RESTORE or FUP DUP operations to copy them to the backup system.
For ENSCRIBE files with alternate key files, after restoring the files to the backup system, if the
name of the alternate key file is in network form, then you must manually alter the system name
of the alternate key file in the file label, replacing the name of the primary system with that of
the backup.
For example, suppose that on the primary system (\PRIMARY) you have a file named
$DATA.TEST.PART0100 with an alternate key file named ALTF0100.
After restoring both files to the backup system (\BACKUP), you must then use a FUP ALTER
command to alter the file label of PART0100 to point to the alternate key file on the backup
system.
FUP ALTER $DATA.TEST.PART0100,
ALTFILE ( 0, \BACKUP.$DATA.TEST.ALTF0100 )
This command does not pertain to NonStop SQL indexes because their labels are automatically
corrected by the MAP NAMES option of the RESTORE utility.
The same issue pertains to Enscribe partitioned files. If the primary partition references
secondary partitions that include the primary system name, you must alter the primary system
name to that of the backup system.
If you have an RDF network for replicating network transactions, then you will need to alter
the partition names to reference the correct names of the backup systems where the partitions
are located.
7. When a new copy of your database is on the backup system and the extractor has logged
the message indicating it has completed its role in the online synchronization operation, issue
the RDFCOM START UPDATE command on the primary system.
NOTE: If your updaters are protecting data volumes that are all configured to the Master
Audit Trail (MAT), you can start the updaters as soon as the duplicate database is on the
backup system and the extractor has issued the RDF event 782. If, however, your updaters
are also protecting data volumes that are configured to one or more auxiliary audit trails, you
must also wait for all of the auxiliary extractors to report 0:00 RTD times before starting the
updaters.
Considerations When Synchronizing Entire Databases
The considerations for online synchronization fall into the following categories:
• Duration of getting a copy of the database prepared on the backup system
• SYNCHDBTIME issues
• CREATE/LOAD issues for NonStop SQL/MP and NonStop SQL/MX tables and Enscribe files
(See Step 4 - Method 1 under “Synchronizing Entire Databases Online” (page 159)
• Enscribe queue file issues
• Different versions of NonStop SQL products on the primary and backup systems
• Moving the duplicated tables and files to the backup system
Duration and Preparation Issues
As indicated in the steps described above, getting a complete copy of your entire database and
placing it on the backup system can take quite a bit of time, and you cannot start the updaters
until the database is fully prepared on the backup system. This leads to an issue that you must
consider. While you are making a copy of the database and then getting it prepared on the backup
system, you must run RDF with UPDATE OFF. This means that audit will accumulate in the RDF
160 Online Database Synchronization