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

101, a single update was logged in the MAT and sent to the backup system, but the primary
system was brought down before the transaction was completed.
When the command for a takeover is issued, the updater processes treat all transactions whose
outcomes are not known as aborted transactions. In this scenario, only the changes related to
transactions known with certainty to have been committed on the primary system are left in the
backup database. Therefore, in the example illustrated in Table 1-1, the audit information
associated with transactions 100 and 101 is backed out of the backup database.
Typically, the extractor process sends audit information to the backup system within a second
after it has been written to the MAT on the primary system, so a minimum number of transactions
are lost when a disaster brings down the primary system.
Tips for Executing Fast Business Takeover Operations
Take online dumps of your backup database as frequently as you take them on your primary
system. In this way, when you need to takeover on your backup system, you will already have
dumps available. Remember, if the RDF UPDATEROPEN attribute is set to PROTECTED, you
must stop the updaters and set it to SHARED before taking online dumps of your backup database.
If your database is NonStop SQL/MP or NonStop SQL/MX and your applications form the typical
requestor-server environment where the requestors send requests into your primary system
from other locations, then you could start your servers on your primary and backup systems.
You must take care that you only route requestor work to your primary system. This leaves your
servers running essentially in standby mode on your backup system.
RDF includes a trigger mechanism whereby user-supplied script can be executed when you issue
a TAKEOVER command on the backup system. The script is completely user-configurable.
You configure a takeover trigger by issuing several SET TRIGGER commands followed by an
ADD TRIGGER TAKEOVER command. Among other things, the SET TRIGGER commands
identify a program-file and an infile.
program-file specifies the name of a Guardian object file be executed when a takeover operation
completes. That could be, for example, $SYSTEM.SYSTEM.TACL or $SYSTEM.RDF.RDFCOM
if you want to execute a TACL macro or RDF commands.
infile specifies the name of an edit file that will be passed to the trigger process when that
process is created. If program-file specifies $SYSTEM.SYSTEM.TACL or
$SYSTEM.RDF.RDFCOM, for example, infile would contain a TACL macro or RDF commands.
This trigger mechanism is the preferred method of performing an RDF takeover and resuming
business activities on your backup system in the shortest time.
The following discussion provides alternative methods for business takeover operations. These
methods might not work for everyone, but you should consider them to see if they might work
for you.
When you lose your primary system because of some unplanned outage, you initiate an RDF
takeover operation. This brings your backup database into a consistent state, typically within a
small number of seconds.
You need to write a program that controls routing requestor work. This program can monitor
one of two mechanisms that report a successful RDF takeover:
• RDF Event 724 reports the successful completion of an RDF takeover for the RDF Control
Subvolume named in the event.
• RDFTKOVR file in the RDF Control Subvolume on your backup system. This file is normally
empty (eof = 0). Upon the successful completion of an RDF Takeover operation, however,
the key word "DONE" is written to the file.
When the program detects a successful RDF Takeover, it can then route requestor work to the
servers on the backup system, and those servers are then ready to resume business on the backup
system.
RDF Subsystem Overview 39