Use a command in the cluster software (the monbegin command for HA Monitor) to start HiRDB on the running system and standby system. If HiRDB cannot be started for either of the following reasons, correct the problem, and then use the pdstart (pdstart -q for a HiRDB parallel server configuration) command to start HiRDB:

• An error occurred that requires setup to be performed again with pdsetup.
• Restart failed when no user command was specified during a restart attempt.

Notes

• Activate the shared resources before executing the pdstart -r or pdstart -R command.
• Execute the pdstart -r or pdstart -R command after HiRDB terminates on the running system and standby system. When the pdstart -r or pdstart -R command is used to start HiRDB, HiRDB is not subject to system switchovers. After a process such as database recovery processing terminates, terminate HiRDB, and then start it on the running system and standby system.
• For a HiRDB parallel server configuration, you must start individual units separately instead of starting the entire system by executing the pdstart command on the unit where the system manager is located. Units that are system switchover targets (units for which pd_ha_unit = nouse is not specified) must be started by executing a cluster software command on each unit. Units that are not system switchover targets (units for which pd_ha_unit = nouse is specified) cannot be started by executing a cluster software command. In this case, directly log on to the corresponding unit's server machine, and then execute the pdstart -q command.

Notes on using MC/ServiceGuard

When the HiRDB termination mode is abnormal termination, the status of the MC/ServiceGuard package is up or running. In this case, use the pdstart command to separately restart HiRDB.

Procedure for starting HiRDB when using ClusterPerfect

To start HiRDB when using ClusterPerfect:

1. Check whether the dncware_daemon on the primary system and secondary system is set to start automatically. You must have root privileges to perform this check.
   # chkconfig -list
   dncware_daemon 0:off 1:off 2:off 3:off 4:off 5:off 6:off
   
2. If the dncware_daemon is off, enter the specification to turn it on.
   # chkconfig dncware_daemon on
   dncware_daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off
   
3. Restart the server machines for the primary system and the secondary system.
4. Activate the DNCWARE operation support system for MMC.
5. Open the ClusterPerfect system information window. This window displays the status of the primary system and secondary system.
6. Start HiRDB.

For details about activation and the window status, see the ClusterPerfect documentation.

The following table lists the methods of terminating HiRDB (in the monitor mode).

Table 26-28 Terminating HiRDB (in the monitor mode)

Condition	Termination method
Terminating both the running system and the standby system	Use the pdstop command to terminate the running system HiRDB. Use a cluster software command (the monend command for HA Monitor) to terminate both the running system and the standby system.
Terminating only the standby system	Use a cluster software command (the monsbystp command for HA Monitor) to terminate the standby system.

Notes on using HA Monitor

When a command to forcibly terminate HiRDB is specified in the termcommand operand of the server definition file, if the monend command of HA Monitor is used to terminate the server without the pdstop command being used to terminate HiRDB, HiRDB is terminated forcibly. Consequently, the start mode used to start HiRDB the next time will be restart mode. To avoid this, when you terminate the service, first use the pdstop command to terminate HiRDB (normal termination or planned termination), and then terminate the server.

Notes on using MC/ServiceGuard

If an MC/ServiceGuard command is used to terminate the package without using the pdstop command to terminate HiRDB, HiRDB is terminated forcibly because it is terminated by the pdstop command in the shell script that was executed to terminate the package. Consequently, the start mode used to start HiRDB the next time will be restart mode. To avoid this, first use the pdstop command to terminate HiRDB (normal termination or planned termination), and then terminate the package.

Notes on using VERITAS Cluster Server

If it is not necessary to stop the system immediately, first use the pdstop command to terminate HiRDB normally. Then use a VERITAS Cluster Server command to terminate the system. Each resource will disconnect from its parent resource in order, and VERITAS Cluster Server will stop. Because HiRDB has already terminated, the execution results of the pdstop command in the offline script will indicate an error, but this is not a problem.

If a VERITAS Cluster Server command is used to terminate the system without first terminating HiRDB normally, the HiRDB termination mode will be forced termination because the pdstop command in the offline script terminates HiRDB. To avoid this, terminate HiRDB normally.

Notes on using Sun Cluster

If the stop method of Sun Cluster is executed without using the pdstop command to terminate HiRDB, HiRDB is terminated forcibly because it is terminated by the pdstop command in the script executed by the STOP_NET method. Consequently, the start mode used to start HiRDB the next time will be restart mode. To avoid this, when you terminate the service, first use the pdstop command to terminate HiRDB (normal termination or planned termination), and then terminate the server.

Notes on using PowerHA

If a PowerHA command is used to terminate a resource group without using the pdstop command to terminate HiRDB, HiRDB is terminated forcibly because it is terminated by the pdstop command in the registered shell script. Consequently, the start mode used to start HiRDB the next time will be restart mode. To avoid this, when you terminate a resource group, first use the pdstop command to terminate HiRDB (normal termination or planned termination), and then terminate the server.

Notes on using ClusterPerfect

If ClusterPerfect is used to terminate a resource group without using the pdstop command to terminate HiRDB, HiRDB is terminated forcibly because it is terminated by the pdstop command in the shell script that was registered. Consequently, the start mode used to start HiRDB the next time will be restart mode. To avoid this, when you terminate a resource group, first use the pdstop command to terminate HiRDB (normal termination or planned termination), and then terminate the server.

Notes on using LifeKeeper

If a LifeKeeper command is used to terminate a resource without using the pdstop command to terminate HiRDB, HiRDB is terminated forcibly because it is terminated by the pdstop command in the shell script that was registered. Consequently, the start mode used to start HiRDB the next time will be restart mode. To avoid this, when you terminate a resource, first use the pdstop command to terminate HiRDB (normal termination or planned termination), and then terminate the resource.

(a) Unit and server operating statuses

The following table describes how to check the operating status of units and servers when a system switchover facility is used.

Table 26-29 Checking the operating status of units and servers when a system switchover facility is used

Command	Output information
pdls -d svr	Host name (the primary system host name is displayed after a system switchover) Unit operating status Server operating status

(b) Checking the system status

The following table describes how to check the system status when a system switchover facility is used.

Table 26-30 Checking the system status when a system switchover facility is used

Command	Output information
pdls -d ha	Host name and system status of the primary system (running/standby/stopped) Host name and system status of the standby system (running/standby/stopped) This command can check the host name and status of the standby system only when IP addresses are not inherited.#1
monshow (only when HA Monitor is used)	Host name and status of the local system#2 Host name and status of the other system#2

#1

When IP addresses are inherited, use a command in the cluster software to check the system status. For details about the information displayed, see the documentation for the applicable cluster software product.

#2

For details about the statuses that can be displayed using the monshow command, see the HA Monitor manuals.

(c) Checking whether a command or utility can be executed

Execute the pdls -d svr command on the system manager unit of the primary system.

• When the termination status of the pdls -d svr command executed on the primary system is 0:
  Because the primary system is the running system, execute the command or utility on the primary system.
  
• When the termination status of the pdls -d svr command executed on the primary system is 8 or when the pdls -d svr command cannot be executed (for example, a remote shell cannot be executed and logon is not possible):
  The secondary system might be the running system. Execute the pdls -d svr command on the system manager unit of the secondary system to check whether the secondary system is the running system.
  
• When the termination status of the pdls -d svr command executed on the primary system or the secondary system is 4:
  Some units might be stopped, or HiRDB is being started or terminated. If units are stopped, start them. If units are stopped because of an error, check the message that was output to the syslogfile, correct the error, and then start the stopped units.
  If HiRDB is being started or terminated, execute the pdls -d svr command repeatedly at intervals of approximately 5 seconds until the termination status is no longer 4. Execute the pdls -d svr command repeatedly using the time specified in the pd_system_complete_wait_time operand as a guideline.
  

When the standby system switchover facility is used, the statistics log files are the two files pdstj1 and pdstj2. These files are created automatically for both the primary system and the secondary system, so the HiRDB administrator must prepare a total of four files. Statistics log files cannot be shared between the primary system and the secondary system.

(a) Creating unload statistics log files

Because statistics log files are distributed to each server machine when a system switchover occurs, you must create unload statistics log files on a specific server machine. We recommend that you create unload statistics log files at the following times:

• When HiRDB starts
• When statistics log files are swapped
• When a system switchover occurs

The following figure shows examples of unload statistics log files created when a system switchover facility is used (standby system switchover (monitor mode)).

Figure 26-92 Examples of unload statistics log files created when a system switchover facility is used (standby system switchover (monitor mode))

Hint

Make the names of the statistics log files the same on all server machines. Do not create unload statistics log files with the same names. Even if you are using the shell script provided by HiRDB (pdstjacm), modify the shell script so that each unload statistics log file has a different name.

(b) Process for collecting statistical information after a system switchover

The following operands specify whether statistical information is collected by the HiRDB on the switchover destination system after a system switchover occurs:

• pd_statistics
• pdstbegin

When A or Y is specified in the pd_statistics operand, or when the pdstbegin operand is specified, the collection of statistical information begins immediately after a system switchover occurs.

If a system switchover occurs when the pdstbegin command is being used to start collecting statistical information, HiRDB on the switchover destination system cannot collect statistical information. To collect statistical information in this situation, you must use HiRDB on the switchover destination system to execute the pdstbegin command.

Also, HiRDB on the switchover destination system determines whether the pdstj1 or the pdstj2 statistics log file will be used. The procedure for determining which statistics log file will be used is the same as when the system switchover facility is not used.

(c) Executing the statistics analysis utility

The statistics analysis utility is executed using the created unload statistics log files as the input information. If a system switchover occurs due to an error, the statistics log information immediately prior to the system switchover is not acquired correctly in the file. For this reason, the execution results of the statistics analysis utility might not be accurate if they are used for tuning or other such activities.