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

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 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.
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 354).
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 described brute force
method might corrupt the database on the backup system. It might also affect the
Stop-Update-To-Time operations.
Audit Trails Pinned by RDF on the Primary System
When you start RDF, the extractor pins the audit trail file it is currently reading in order to prevent
TMF from rolling that file over. This operation of pinning the audit trail file by the extractor is
particularly useful if the extractor falls behind for some reason in that it keeps that audit trail file in
place for the extractor, thereby allowing the extractor to resume operations immediately when the
cause for it falling behind has been resolved.
120 Critical Operations, Special Situations, and Error Conditions