RDF/IMP and IMPX System Management Manual (RDF 1.3+)

Managing RDF
Compaq NonStop™ RDF/IMP and IMPX System Management Manual—522204-001
5-20
Checking Exception Files for Uncommitted
Transactions
When a takeover completes on the backup system, the purger logs an RDF event 888
specifying a MAT position (sno, rba). Subsequently, when the primary system is once
again online and you are ready to switch the applications back to the primary, you first
initiate a TMF file recovery to MAT position on the primary system specifying the
logged MAT position. TMF restores the primary database to the exact same state that the
backup database was in when the takeover operation completed.
You then configure the RDF subsystem to run from the backup to the primary system to
bring the primary database back up to date with updates that took place while the
primary was down.
When the primary database is fully current, you then perform a planned switchover from
the backup to the primary system, and restart your applications on the primary system.
Checking Exception Files for Uncommitted Transactions
After all RDF processes on the backup system stop, you should check each exception
file for data.
If the end-of-file value is zero for all exception files on the backup system, the receiver
received a commit/abort record for every transaction for which any audit data reached
the backup system.
If data is present in the exception files, some audit records were successfully transmitted
to the backup system, but the associated commit/abort records were not. For such
transactions, the updaters have no indication whether all data associated with the
transaction made it to the backup system. Therefore, RDF treats these transactions as if
they were aborted (that is, audit data for these transactions that was applied to the
backup database is backed out). This method provides an absolute guarantee that the
backup database will be 100 percent consistent with regard to known transactions on the
backup system. Your database administrator might be able to use the RDFSNOOP utility
to examine unapplied image records that are pointed to by the exception files. See
Appendix B, Additional Reference Information
for information about RDFSNOOP.
Note. You always use the logged MAT position to initiate the file recovery operation, even if the
RDF configuration is replicating auxiliary audit trails.
Caution. The absence of exception file records after a successful takeover operation does not
necessarily indicate that the backup database is logically identical to the primary database. It is
possible that no audit data reached the backup system for some transactions committed on the
primary system. That is, the transaction was started and committed, but the primary system
failed before the associated audit was transmitted to the backup system.