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

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 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 once again synchronized with your primary database.
TMFCOM ABORT TRANSACTION With AVOIDHANGING Option on Primary System
Under some circumstances, the TMF Backout process on the primary system is not able to back
out transactions from a data file (for example, hung transactions). If this situation arises, and if
the file is protected by RDF, the user should avoid issuing the TMFCOM ABORT TRANSACTION
command with the AVOIDHANGING option to abort such transactions. Use of this command
makes RDF write internal entries into the ZFILEINC file on the backup RDF system, thereby
stopping the purger from purging old image trail files thereafter. For details about the ZFILEINC
file, see “RDF System Files” (page 333).
If possible, the user should try to resolve the cause of the Backout errors first (for example, ALTER
MAXEXTENTS of the file if it is an error 45) and then issue TMFCOM ABORT TRANSACTION
without any option.
If RDF internal entries are written into the ZFILEINC file due to the TMFCOM ABORT
TRANSACTION command with the AVOIDHANGING option, then a "brute force" method can
be used to restart the purger activity. That is, perform a PURGEDATA operation on the ZFILEINC
file. This method is to be used only if the user has resolved the hung transactions on the primary
system without File Recovery or Volume Recovery, and if the transactions associated with entries
in the ZFILEINC file would never need to be undone on the backup system.
CAUTION: If the transaction associated to an RDF internal entry listed in the ZFILEINC file
needs to be undone as a part of an RDF TAKEOVER operation, then using the above-described
brute force method might corrupt the database on the backup system. It might also affect the
Stop-Update-To-Time operations.
Stopping RDF
If the communications lines between the primary and backup systems are up, there are two ways
to stop RDF:
1. Issue a STOP RDF command on the primary system.
2. Issue a TMFCOM STOP TMF command on the primary system. After the RDF updaters
have reached the TMF shutdown record, RDF stops and then TMF stops.
Stopping RDF 129