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

Managing RDF
HP NonStop RDF/IMP and IMPX System Management Manual—524388-001
5-22
Checking Exception Files for Uncommitted
Transactions
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.
If the purger issues an 858 event message, file recovery on the primary system is not
possible.
Checking Exception Files for Uncommitted Transactions
Exception files are used by updaters to store information about each audit record that
the updater undoes during the three possible undo passes. An exception record logs
information about a specific audit record that the updater has undone. This may or
may not be useful information for you. If the volume of audit is small, then logging an
exception record for each record undone may have only a slight performance impact
during the takeover operation. If, however, the volume of audit to be undone by an
updater is large (e.g thousands of records), then logging an exception record for each
record undone could have an impact on the takeover operation.
You can choose whether you want exception records for each transaction when you
configure the RDF UPDATEREXCEPTION attribute. If you set it ON, the updater logs
an exception record for each audit record on which it executes undo. If set OFF, then
an exception record is only written for the first and last audit records undone. Please
note that if you set UPDATEREXCEPTION OFF, you can still determine which
transactions were undone by using the READLIST utility to read the undo files.
Your database administrator can use the RDFSNOOP utility to examine exception
records in exception files. See Appendix B, Additional Reference Information for
information about RDFSNOOP.
Preparing for Application Processing on the Backup System
See Tips for Executing Fast Business Takeover Operations in section 1 for information
on how you can execute an RDF takeover and resume business activities on your
backup system in the shortest amount of time.
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.