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

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

By using the TAKEOVER ! version of the TAKEOVER command you eliminate the Expand
level-four timer and the prompt.
For super fast takeover, see “How to Plan for the Fastest Movement of Business Operations to
Your Backup System After Takeover” (page 144) .
Issuing the TAKEOVER Command in an Obey File
You have the following three options to issue the TAKEOVER command through an OBEY file.
1. As stated in the section entitled “Using RDFCOM Noninteractively (without an IN File)”
(page 102) , you can issue RDFCOM commands in a TACL obey file or a script file. You issue
the command as follows:
RDFCOM <control-subvol-name>; Takeover !
Please note that you run this command on the backup system and that the
<control-subvol-name>
is the name that identifies the specific RDF subsystem for which
you want to execute the Takeover command. It is suggested that you use the ! option for
simplicity. Otherwise you must configure your script file to handle the prompts that RDFCOM
asks when executing the Takeover command.
2. The second option is to write the TAKEOVER command appended with the bang (!) character
in an EDIT file and OBEY the file from the RDFCOM prompt.
For example, consider an EDIT file
RDFTKOV
that has the following content:
TAKEOVER!
Now, you can obey the file RDFTKOV from the RDFCOM prompt, as shown below:
RDFCOM] obey RDFTKOV
3. The third option is to write the TAKEOVER command appended with the bang (!) character
in an EDIT file and pass it as an IN file to RDFCOM.
For example, consider an EDIT file RDFTKOV has the following content:
TAKEOVER!
Now, you can use the EDIT file RDFTKOV as an INFILE to RDFCOM, using the following
command:
RDFCOM /IN RDFTKOV/
NOTE: RDFCOM does not allow the TAKEOVER command without the bang (!) character
when issued in an IN file / OBEY file.
Monitoring Takeover Outcome
You can monitor the status of RDF takeovers by issuing a STATUS RDF command on the backup
system or by examining the events in the EMS log.
When all of the updater processes have stopped, the purger logs either the RDF event number
724 or 725 before stopping. Event 724 indicates that the takeover completed successfully. Event
725 indicates that it did not, and you should reissue the TAKEOVER command. Event 724 is
always followed by event 735, which indicates the last MAT position seen by the receiver process.
The 735 event is used primarily for triple contingency. These events will be followed by either
RDF event 888 or 858. See
“Restoring the Primary System” for more information.
For RDF network takeover considerations, see Chapter 14 (page 295) .
For super fast takeover, see “How to Plan for the Fastest Movement of Business Operations to
Your Backup System After Takeover” (page 144) .
142 Critical Operations, Special Situations, and Error Conditions