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

image trails. When synchronizing databases, you should configure image trail volumes that have
a lot of free space for image files.
The key problem you want to avoid is where your steps to obtain the copy and prepare it on the
backup system take so long that your image trails run out of space before you are able to start the
updaters. If the image trails fill, then this causes the extractors on the primary system to stop sending
audit data to the receivers because those receivers have no place to put the audit data. Because
the extractors pin audit trail files to avoid having TMF delete files before the extractors have finished
with them, this pinning, if it lasts long enough, could lead in turn to the situation where no new
transactions are allowed by the TMF product on the primary system.
You can avoid the above situation by configuring enough image trails, and ensuring that the image
volumes have sufficient disk space. The more image trails you have, the safer you are. Once the
synchronization process has completed, you can always reduce the number of image trails by
stopping the RDF product and reconfiguring a new RDF environment that has fewer image trails.
Alternatively, if your database is so big that it could take more time to obtain the copy and prepare
it than you have image space for, then you might want to synchronize one part of the database
at a time. When that operation has completed, you would then synchronize the next portion. See
the discussion on partial database synchronization and the issues pertaining to it that follows.
SYNCHDBTIME Issues
With the SYNCHDBTIME option in the INITIALIZE RDF command, there are three special cases
you might need to consider:
• Enscribe create operations
• NonStop SQL/MP and NonStop SQL/MX Shared Access DDL operations
• TMF shutdown operations
Enscribe Create Records
If you created the same Enscribe file on the primary and backup systems prior to execution of the
INITIALIZE RDF command, and if the extractor’s restart position is located before the audit record
for the create operation on the primary system, you must remember to purge that file on the backup
system. Otherwise, when the updater tries to replicate the create operation, it will report a File
System error 10 (File Already Exists) and restart. It continues to restart and attempt to create the
file until you purge the existing file on the backup system.
Stop-RDF-Updater Records
Stop-RDF-Updater records in the MAT are associated with committed NonStop SQL DDL operations
performed on the primary system with the WITH SHARED ACCESS option. Although such operations
can be performed on the primary system without stopping your applications, they must be performed
manually on the backup system after all updaters have shut down in response to the same
Stop-RDF-Updater record.
As a general rule, you should not initialize the RDF subsystem to a synchdbtime if you recently
performed a NonStop SQL operation with SHARED ACCESS on the primary system. For example,
suppose you have a NonStop SQL/MP (tableA) that contains the range of keys A through Z
and you just moved its partition boundary such that tableA now contains only the keys A through
M and a new table (tableB) contains the keys N through Z. Suppose also that you performed
this operation manually on the backup system.
If you then initialize the RDF subsystem to a point in the MAT prior to the Stop-RDF-Updater record
associated with the partition boundary change and an updater encounters audit records associated
a key N through Z, the updater will report an error because it will try to apply the audit records
to tableA (which used to contain it, but now does not), and the audit records will not be applied
to the backup database. In this particular case the database is not corrupted, but data corruption
could occur for other NonStop SQL/MP or NonStop SQL/MX DDL SHARED ACCESS operations.
Synchronizing Entire Databases Online 161