RDF System Management Manual for H-Series RVUs (RDF 1.8)

8. When your loaded 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 loads and getting the database prepared on the backup system
• SYNCHDBTIME issues
• CREATE/LOAD issues for NonStop SQL/MP tables and Enscribe files
• Enscribe queue file issues
• Different versions of NonStop SQL/MP 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, creating, loading, and placing the copy of the database
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 loading the data, and then getting the database 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 load and preparation steps 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 load and prepare 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.
Synchronizing Entire Databases Online 157