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

4. When the purger has logged RDF event 852, perform the same DDL operation on the backup
system.
5. START RDF on the primary system.
6. Start application processing on the primary system.
Resynchronizing Databases
There are two ways of resynchronizing your primary and backup databases: offline and online.
With offline resynchronization you must first stop your applications and TMF on the primary system.
With online resynchronization, however, you can resynchronize entire databases, selected volumes,
a single volume, or individual tables and files while your applications continue to run on the primary
system.
The remainder of this chapter describes how to do offline resynchronization. For information about
online resynchronization, see Chapter 7 (page 157).
To resynchronize the primary and backup databases, you need to make all backup database files
or tables logically identical to the primary database files or tables when there is no audit data to
be processed for the files or tables. If you know which files or tables are not synchronized,
resynchronize the databases only on the volumes that contain those files or tables.
There is no audit data to be processed for a volume at the following times:
• Immediately after TMF has been started for the very first time and no applications have been
started yet
• When the RTD time is zero for the volume’s updater process, and no audit data is being
generated by any application while the files or tables are being duplicated
• When TMF is stopped (without the ABRUPT option)
Make sure the primary and backup databases are synchronized if any of the following should
occur:
• A TMF file recovery operation to a timestamp or to first purge occurs, after which only the
affected database tables or files need to be resynchronized.
• Asterisks (****) appear in the final column of the STATUS RDF display, indicating that an
updater process has experienced an unexpected file-system error.
NOTE: Resynchronization is not always necessary, however, after a file-system error in an
RDF process. For example, an updater process reporting an error 122 will restart.
• TMF is deleted and reconfigured, or RDF is reinitialized, after a STOP RDF command is issued
at the primary system.
If RDF fails and reports an event whose recovery text indicates that database resynchronization is
required, you must resynchronize the backup and primary databases.
Resynchronizing Entire Databases Offline
To resynchronize an entire database offline, you must stop TMF, initialize RDF to the TMF shutdown
timestamp, and then copy the complete database from the primary system to the backup system.
Alternatively, in an environment where there are multiple databases and applications, but RDF is
protecting only one of those databases, stopping TMF might not be desirable. In this case, you
can stop the applications associated with the RDF-protected database, copy the database from
the primary system to the backup system (there are several ways of doing this), reinitialize RDF
using the INITTIME option, and start RDF.
If you are unsure about which tables or files might not be synchronized, you need to compare the
questionable tables or files between the primary and backup databases and then, based on that
evaluation, resynchronize some of the database objects.
Resynchronizing Databases 155