RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

audit to be undone by an updater is large (for example, thousands of records), then logging an
exception record for each record undone could slow down the takeover work of each updater.
You can choose whether you want an exception record for each audit record undone during the
takeover operation 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 340).
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.
How to Plan for the Fastest Movement of Business Operations to Your Backup System
After Takeover
The following discussions should be carefully considered when setting up your RDF environment
because spending the time to do that will then simplify and speed up your ability to takeover and
resume business operations on your backup system after you have lost the primary to an unplanned
outage. The same considerations also apply to orchestrating a planned switchover.
1. RPO and RTO
RPO stands for Recovery Point Objective and represents how much audit you are willing to
lose in the event of an unplanned outage of your primary system. Your objective is to have
the highest possible RPO, meaning you will lose the least amount of data. RDF/IMPX already
delivers the maximum RPO that any asynchronous replication product can deliver on NonStop
by virtue of RDF’s private audit reading logic, which allows it to move audit off of the primary
system faster than any other product, thereby minimizing loss of data. With the RDF/ZLT
product, there is no loss of data at all.
RTO stands for Recovery Time Objective and represents how much time you can afford to be
down before resuming business operations on your backup system. Your objective should be
to have the lowest possible RTO. While the RDF takeover operation itself normally takes only
a small number of seconds, there are many other issues to consider in order to achieve an
optimal RTO, and this is the focus of the discussion that follows. As a rule, the more you plan
in advance, the more you can lower your RTO.
2. Be Sure You Have All You Need
While RDF keeps your backup database up to date, there are doubtless many other files and
objects you need on your backup system in order to resume business operation there. Use the
NonStop AutoSync product to move and/or keep up to date your unaudited files, such as text
files, scripts, executable objects, applications, etc. Be sure you have every file that you need
on your primary system also on your backup system. Failure to move all files to your backup
system and keep them up to date may lead to lengthy delays in your ability to resume business
operations on your backup system.
3. Takeover regular online dumps of your backup database
A simple example provides the best explanation for this recommendation. Assume for the
moment that you never take online dumps, you lose your primary system, you execute the RDF
takeover command, you resume business operations on your backup system, and then you
encounter a complete media failure of one or more disks on which your database resides.
Without online dumps, you may never be able to recover the lost data.
Takeover Operations 135