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

The file recovery TOMATPOSITION is a special usage that achieves synchronization itself. If your
RDF primary system has failed, you have executed an RDF takeover operation on your backup
system without RDF/ZLT, and you have subsequently brought your primary system back online,
you can resynchronize the database on your recovered primary system with file recovery
TOMATPOSITION. When the takeover has completed on your backup system, RDF normally logs
an RDF event 888. This event provides you with a master audit trail sequence number and relative
byte address that you can use for file recovery TOMATPOSITION on your recovered primary
system. The result of this operation puts the database on your primary system into synchronization
with the database on your backup system at the time when the takeover operation completed. If
you started application processing on your backup system after the completion of the takeover
operation, you then need to configure a new RDF subsystem to replicate all changes made to the
database on your backup system to the database on your primary system.
WARNING! File Recovery with TOMATPOSITION should only be used when recovering your
primary system after an RDF Takeover operation on your backup system. If you use the
TOMATPOSITION for any other reason, it will require database synchronization just like File
Recovery to a timestamp or first purge.
File Recovery on the Backup System
You are encouraged to take online dumps on your backup database on a regular basis for the
following reasons:
• If you have lost your primary system and have taken over on your backup system, the online
dumps can be used for any type of file recovery operation provided the redo end point is
located after all audit data that was generated during the RDF takeover. For example, a file
recovery to a timestamp must be to a timestamp after the time when the RDF takeover
completed.
• If RDF is running from your primary to your backup system and you lose one or more disks
on your backup system, you should stop the RDF updating, perform a simple file recovery on
the backup system to recover the files on the affected disks, and then restart RDF updating.
You should not perform a file recovery to a timestamp, first purge, or TOMATPOSITION on your
backup system if the location occurs prior to an RDF takeover location. Those file recovery operations
normally are used to recover a database that has been corrupted.
Under normal circumstances, the best way to recover the backup database is to resynchronize it
with your primary database. Because that can involve significant time and effort, you should
consider using the following method instead (assume that the system clocks on the primary and
backup systems are set to the same time):
• Stop RDF.
• Perform file recovery to a timestamp on the backup system.
• Determine the duration of the longest running transaction on your primary system. Subtract
this amount of time from the time used for the start of the file recovery operation. If you don't
know the duration of the longest transaction, it is better to overestimate than to underestimate
(use an arbitrary number, such as 10 minutes). There is nothing wrong with initializing RDF
to a point further back in time than is necessary.
• On the primary system, reinitialize RDF with the INITTIME option, specifying the calculated
timestamp from the above step.
• Restart RDF.
When the updaters have caught up with transaction activity on the primary system, the backup
database is again synchronized with your primary database.
122 Critical Operations, Special Situations, and Error Conditions