RDF System Management Manual for H-Series RVUs (RDF 1.8)

Takeover and File Recovery
After you initiate a takeover, it is possible that the last committed transactions did not make it
to the backup system (meaning that the backup and primary databases are not synchronized).
If the 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
command with the TOMATPOSITION option on the primary system specifying the logged MAT
position from the 888 event. TMF restores the primary database to the exact same state that the
backup database was in when the takeover operation completed.
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.
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 might or might not be useful information
for you. If the volume of audit is small, then logging an exception record for each record undone
might have only a slight performance impact during the takeover operation. If, however, the
volume of audit to be undone by an updater is large (for example, 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. 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. For information about RDFSNOOP, see Appendix B (page 329).
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.
Preparing for Application Processing on the Backup System
See “Tips for Executing Fast Business Takeover Operations” (page 39) for information on how
you can execute an RDF takeover and resume business activities on your backup system in the
shortest amount of time.
Before application processing starts on the backup system following a successful takeover
operation, you might need to update statistics for NonStop SQL/MP database tables and recompile
NonStop SQL/MP program files.
138 Managing RDF