Different Nonstop Sql Product Versions; Moving Duplicated Tables And Files To The Backup System - HP NonStop RDF J-series RVUs Management Manual

If the file is empty and contains zero records, you must reissue your original command again,
and recheck the contents of the target file.
FUP COPY QUEUE1, QUEUE2, FIRST 1, SHARE
FUP COPY QUEUE2,, H
The target file, QUEUE2 in this example, is not ready for synchronization until it has at least one
record in it. Therefore, you might need to repeat the above operation until a record appears.
You could also copy the empty file to the backup system, insert a record into the file on the
backup system, and delete the inserted record:
1. Start a transaction, do a WRITE to the empty queue file, and commit the transaction.
2. Start a new transaction, do a READUPDATELOCK on the record, and commit the transaction.
This procedure pops the inserted record from the file, but leaves the special "dummy" record
in the 0th position. You must do this operation before you start RDF updating.
For information about the special "dummy" record in Enscribe Queue Files, see the information
about queue files in the Enscribe Programmer's Guide.

Different NonStop SQL Product Versions

If you have different versions of the NonStop SQL product of choice on your primary and backup
systems, see the SQL/MP Version Management Guide(for SQL/MP users) or SQL/MX Database and
Application Migration Guide(for SQL/MX users) for information about what you can do and how
to do it.
Three of the more common issues are:
• If your primary system has a higher version of the NonStop SQL/MP or NonStop SQL/MX
product than the backup system, then the tables on the primary system must not make use
of features not supported by the lower product version. Failure to comply with this will
result in errors when attempting to create the duplicate tables.
• You can create the duplicate tables on the backup system and then load them over the
network from the primary system, but you must be knowledgeable about issues regarding
differences in table and catalog versions. See the SQL/MP Version Management Guide or
SQL/MX Database and Application Migration Guide.
• You can create and load the duplicate tables on the primary system and then move them to
the backup system using SQLCI DUP commands or BACKUP/RESTORE and tapes. In either
case, however, the tables must be registered in a catalog on the backup system. Again, you
must be knowledgeable about issues regarding differences in table and catalog versions.
See the SQL/MP Version Management Guide or SQL/MX Database and Application Migration
Guide.

Moving Duplicated Tables and Files to the Backup System

If you created the duplicate files and tables directly on the backup system and loaded them from
the primary system, you can start the RDF updaters without any further considerations.
If you created the duplicate files and tables on the primary system by Method 1 or Method 2 and
then moved them over to the backup system, however, you must be aware of the following:
• If you move duplicate partitioned Enscribe files whose volume mappings differ between
the primary and backup systems, you must use a FUP ALTER command to alter the file
labels of the duplicate files on the backup system so they reflect the correct volume mapping
of the various partitions on the backup system.
For example, suppose you have a partitioned Enscribe file on the primary system whose
primary partition is on $DATA1 and secondary partition is on $DATA2. If, on the backup
system, the primary partition is on $DATA1 but the secondary partition is on $DATA3, you
must change the volume name in the file label of the duplicate secondary partition from
$DATA2 to $DATA3:
Synchronizing Entire Databases Online 173