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

c. If you use the same application for query processing as well as read/write access, and
you are already performing query processing on your backup database, you will need
to have the application close all files currently open for read-only access, and then reopen
them for read/write access after the RDF takeover. In this sense, it may be advantageous
to have one application that performs query processing and another that does read/write
operations.
d. If your applications have files open for read access, then your operations staff can close
files and/or restart the applications while the decision is made to takeover or not.
– If not takeover, then allow query processing to resume, as normal;
– If takeover, then you have already closed the files and you can proceed with next
tasks need to commence work on your backup system.
9. For Enscribe files, applications typically open these before starting work; the points raised for
8c and 8d above apply here as well.
10. After RDF Takeover, use scripts to automate the remaining tasks that need to be done as quickly
as possible. These tasks typically involve the following:
a. Typically the most complicated task in moving business operations from the primary to
the backup system is switching your communications lines. Automate this as much as
possible by writing one or more scripts to handle the switching programmatically.
b. Update statistics for SQL tables? You are advised to keep these as up to date as possible
during normal operations. You must stop the updaters to do this, but perhaps it could be
scheduled during periods of low updater activity.
c. Recompile SQL applications? Use CHECK INOPERABLE PLANS (NonStop SQL/MP feature
that starts auto recompilation). If you use NonStop AutoSync, you can configure a trigger
that will automatically start recompilation whenever NonStop AutoSync copies a new
version of the object to the backup system.
d. Does your data have the primary system's node name and/or number embedded in the
data? If yes, you may need to run a script that will change the name and number to those
of the backup system.
e. Handle any issues involving file opens if these have not already been addressed while
waiting for takeover authorization.
f. Handle any tasks that pertain to your specific operations. There may be any number of
things to be done. One task, for example, may be to determine what transactional work
was either never completed on the primary at the time of the disaster and what was
undone by RDF during the takeover; this allows you to determine what work you might
need to have your applications reprocess on the backup system.
g. If your Pathway servers are frozen, thaw them now.
h. Route work to servers on backup system if this is a separate step from step “f”.
11. If you set up an RDF takeover trigger, RDF automatically executes the trigger's script immediately
after the successful completion of the RDF takeover. This script might handle all or many of
the different tasks listed above. Alternatively, when you know the RDF takeover has completed
successfully, you can execute such a script yourself. You can determine the outcome of the
RDF takeover in the following ways:
a. RDFTKOVR file can be used as a semaphore; this file in the control-subvolume is empty
when created (EOF is 0) and stays empty until an RDF takeover has completed, at which
time RDF writes a short text message to signal the takeover has successfully completed.
You might want to write a program to monitor this file and, as soon as EOF changes to
a non-zero value, have your program execute your script.
b. Write a process that monitors the RDF event log for RDF event 724 (RDF Takeover
Completion event) and execute you script.
Takeover Operations 137