HP NonStop RDF, Руководство по управлению

Страница: 146 / 478

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.
12. Test Your Switchover/Takeover Procedures
You may not know whether you have everything you need on your backup system to move
business operations from your primary system to your backup until you perform that task.
If you wait until you actually encounter a disaster and must move business operations to
the backup system, you may find that you are missing important items that you need.
Therefore, the best way to be certain is to perform either a takeover or switchover operation
146 Critical Operations, Special Situations, and Error Conditions