HP NonStop RDF, Руководство по управлению

Страница: 170 / 478

Duration and Preparation Issues
As indicated in the steps described above, 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 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
170 Online Database Synchronization