RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

• 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 362).
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.
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.
When the extractor pins an audit trail file, it does this by sending a message to TMF, asking TMF
to keep the file pinned until the extractor no longer needs it, so in reality it is TMF who actually
pins the file on behalf of RDF. When the extractor rolls over from one audit trail file to the next,
it unpins the earlier file and pins the next file.
NOTE: TMF keeps the extractor's audit trail file pinned even if you stop RDF. This ensures that
the file is in the audit trail for the extractor when you next start RDF.
If TMF has an audit trail file pinned and it wants to roll over that file, then it generates a TMF
event to indicate that it cannot unpin the file because it is keeping the file pinned on behalf of
RDF. In this event, TMF includes in that event the name of the RDF control subvolume for the
RDF subsystem that wants the file pinned. Thus you can always determine which RDF subsystem
is holding up TMF.
If the extractor has an audit trail file pinned, the extractor is either stopped or stalled for some
reason, and this is affecting TMF, there are two ways to unpin the audit trail file.
Responding to Operational Failures 131