How To Plan For The Fastest Movement Of Business Operations To Your Backup System After Takeover - HP NonStop RDF J-series RVUs Management Manual

Your database administrator can use the RDFSNOOP utility to examine exception records in
exception files. For information about RDFSNOOP, see
CAUTION:
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.
Therefore, taking an online dump before resuming business operations is important, but
when do you do it? If you wait until after the RDF takeover operation has completed, then
it could take many hours before the online dumps complete, and only then would it be safe
to resume business operations. Thus, not taking regular online dumps of your backup
database can lead to a significant length of time before you can safely resume business
operations on your backup system. If, however, you take regular online dumps of your
backup database as well as take audit dumps, then you can start business operations as soon
144 Critical Operations, Special Situations, and Error Conditions
The absence of exception file records after a successful takeover operation does not
Appendix B (page 359).