RDF System Management Manual

Table Of Contents
Online Database Synchronization
HP NonStop RDF System Management Manual524388-003
7-8
Considerations When Synchronizing Entire
Databases
Enscribe Queue File Issues
For ENSCRIBE queue files, a different method of obtaining the fuzzy copy is required.
You must use the FUP COPY command with the SHARE option specified, and with
“FIRST 1” specified. For example, the following command copies the contents of file
QUEUE1 to QUEUE2.
FUP COPY QUEUE1, QUEUE2, FIRST 1, SHARE
To ensure that your target file, QUEUE2 in the above example, has the proper content,
copy the content of the target file to the screen by using the following command:
FUP COPY QUEUE2,, H
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 may 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 as follows:
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
Section 7, Queue Files of the HP NonStop Enscribe Programmers Guide.
Different NonStop SQL/MP Product Versions
If you have different versions of the NonStop SQL/MP product on your primary and
backup systems, refer to the HP NonStop SQL/MP Version Management Guide for
information about what you can do and how to do it.
Three of the more common issues are as follows:
If your primary system has a higher version of the NonStop SQL/MP 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