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

Duration and Preparation Issues
As indicated in the steps described, 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 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 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 or suspended (based on the
value of the UPDATERNSASUSPEND attribute) 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.
160 Online Database Synchronization