RDF System Management Manual

Managing RDF
HP NonStop RDF System Management Manual—524388-003
5-25
Checking Exception Files for Uncommitted
Transactions
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.
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.
Note. You always use the logged MAT position from the 888 event message 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.