(a) Standby-less system switchover (effects distributed) facility

The following table describes the commands to be executed when starting HiRDB.

Table 26-52 Commands to be executed when starting HiRDB (when using the standby-less system switchover (effects distributed) facility)

Objective	Command to execute	Remarks
Starting the regular unit	pdstart -q	Started when the regular unit is stopped.
Starting the accepting unit	pdstart -q	Guest BESs in the accepting unit are also started at the same time.
Starting the host BES or starting the guest BES	pdstart -u -s	If a guest BES is stopped, it is placed in accepting status. HiRDB starts automatically, so you do not normally need to use this command. Use this command only when a back-end server or its standby server was stopped explicitly.

Starting the entire system

The following table lists and describes the method for starting the entire system.

Table 26-53 Startup method for the entire system

Input location	Command	Operation
Unit where the system manager is defined	pdstart	Starts the entire system.

The following explains the process of starting the entire system:

• Server startup: Execute server startup for all host BESs and guest BESs of each unit.

The figure below shows an example of starting the entire system when the standby-less system switchover (effects distributed) facility is used.

To start the entire system, enter the pdstart command from the unit where the system manager is defined, as is the case when the standby system switchover facility is used. The guest BESs in each unit are placed in accepting status automatically.

Figure 26-101 Example of starting the entire system when the standby-less system switchover (effects distributed) facility is used

The table below lists the system startup operations. When system startup is complete, the KFPS05210-I message is output.

Table 26-54 System startup operations

Start type	If standby-less system switchover (effects distributed) facility is applicable to the unit
	No	Yes
System startup	Starts all units (All servers start).	Starts all servers (Not all units start).
Solo-startup of the unit where the system manager is defined (after abnormal termination of the unit where the system manager is defined)	Starts one front-end server, one dictionary server, and one back-end server.	Starts one front-end server, one dictionary server, and one back-end server.
Solo-startup of a unit in an HA group	--	--
Solo-startup of other units	--	--

Legend:

--: Not applicable

Starting a unit

The following table describes how to start a unit.

Table 26-55 Unit startup method

Input location	Command	Option		Operation
		-q	-u
Unit where the system manager is defined	pdstart	No	Yes	Starts the target unit.
		Yes	No
Target unit	pdstart	Yes	No

Startup modes for units

The table below lists the unit startup modes. Whether a unit is to be started normally or restarted is determined exclusively by the unit's previous termination mode. It is not affected by the presence or absence of a host BES or guest BES that starts, or by normal start or restart of the server that starts.

Table 26-56 Unit startup modes

Unit's previous termination mode	Host BES or guest BES		Unit startup mode
	Startup of start server	Startup of restart server during startup of start server
Normal stop	No	No	Normal start
	Yes	No
	Yes	Yes
Planned stop, forced termination, or abnormal termination	No	No	Restart
	Yes	No
	Yes	Yes

When the standby-less system switchover (effects distributed) facility is used, determination and processing of restart or normal start is executed for each user server. Therefore, the unit can start normally, even when another server in the unit has been forcibly or abnormally terminated or is running on another unit in the HA group.

Also when the standby-less system switchover (effects distributed) facility is used, a unit is restarted after it has been forcibly or abnormally terminated. Because restart processing is executed for each user server, there is no resource (database) to be restored for the unit itself. However, as usual, the operations during unit restart are different from those during a normal start, as described in the following table.

Table 26-57 Significance of unit restart

Item	Content
Configuration modification check	Checks for definition modifications that increase system resources (such as shared memory) to eliminate the risk of a restart failure (the number of guest BESs that can be accepted can be changed).
System startup completion check	If there is one front-end server, one dictionary server, and one back-end server available during the restart of the unit where the system manager is defined, system startup is considered complete and service begins. During normal startup of the unit where the system manager is defined, the system waits for all servers to finish starting. However, during a restart of the unit where the system manager is defined, the number of servers to wait for is reduced, resulting in an earlier resumption of service acceptance.
Unit run ID inheritance	Unit run ID is inherited before the unit stops. It is used as the reference for output of the KFPS01826-I message during unit startup and for regular and automatic execution of pdcspool.

Unit startup example

The figure below shows an example of unit startup when the standby-less system switchover (effects distributed) facility is used. Start the unit as follows:

• Enter the pdstart -u command from the unit where the system manager is defined.
• Log onto the host where the unit is located and enter the pdstart -q command.

As the unit starts, the system changes the status of the following guest BESs:

• Cancels the accepting status for guest BESs in the unit (Automatic status change 1 in the figure)
• Guest BESs corresponding to host BESs in the unit (Automatic status change 2 in the figure)
  

  Figure 26-102 Unit startup example when the standby-less system switchover (effects distributed) facility is used

  

Unit startup example when there is no running system back-end server

The figure below shows an example of starting a unit that has no running system back-end server when the standby-less system switchover (effects distributed) facility is used.

The following methods are available for starting the unit:

• Entering the pdstart -u command from the unit where the system manager is defined
• Logging onto the host where the unit is located and entering the pdstart -q command

As the unit starts, the system changes the status of the guest BESs in the unit (Automatic status change 1 in the figure).

Figure 26-103 Example of starting a unit that has no running system back-end server when the standby-less system switchover (effects distributed) facility is used

You can determine unit startup completion based on the output of the KFPS05110-I message:

• For a unit that does not use the standby-less system switchover (effects distributed) facility, the message is output when startup of all servers in the unit has finished.
• For a unit that uses the standby-less system switchover (effects distributed) facility, the message is output when startup of all running system servers in the unit has finished.

Starting a server

The following table describes how to start a server.

Table 26-58 Startup method for a server

Input location	Command	Option			Operation
		-q	-u	-s
Unit where the system manager is defined	pdstart	No	No	Yes	Starts the target servers in all active units in an HA group#1
		Yes	No	Yes	Starts the host BES (-u can be omitted)#2

#1

The back-end servers in one of the units that are active in the HA group become the running servers and the other units are placed in accepting status.

#2

When the target back-end servers are started successfully as running servers, the active units in the HA group are placed in accepting status automatically.

The following table lists the processing results during server startup depending on the cluster software product that is used.

Table 26-59 Processing results during server startup

Cluster software product	Server type	Other units while the applicable server is active	Activation on the applicable host#3	Server startup result
HA Monitor	Host BES	No	--	Active
		Yes	--	Accepting
	Guest BES	No	--	Waits for running system to start#1
		Yes	--	Accepting
Hitachi HA Toolkit Extension	--	No	Yes	Active#2
			No	Accepting
		Yes	Yes	--
			No	Accepting

Legend:

--: Not applicable

#1

HA Monitor does not include the concepts of the running server and the standby server once a server has stopped. When the server starts again, the running system and the standby system are determined anew. In such a case, a secondary system (standby system in the default mode) waits for the running system to start when there is no running system. Therefore, if an active guest BES is stopped and then restarted at the same unit, it waits for the running system to start, and does not return to active status until the monact command is executed.

#2

Even after it stops a server, Hitachi HA Toolkit Extension makes the server appear to the cluster software to remain active. Therefore, when active servers, including guest BESs, are stopped and started on the same unit, they are placed on active status again.

#3

This is equivalent to package activation in MC/ServiceGuard or group start in VERITAS Cluster Server.

Server startup example

The figure below shows an example of starting a running system server when the standby-less system switchover (effects distributed) facility is used.

The following method is available for starting the running system server:

• Entering the pdstart -s command from the unit where the system manager is defined

As the server starts, the system changes the status of the guest BESs corresponding to the server (Automatic status change in the figure).

To check whether the server is the running system, use the pdls -d ha command.

Figure 26-104 Example of starting a running system server when the standby-less system switchover (effects distributed) facility is used

The figure below shows an example of starting a standby system server when the standby-less system switchover (effects distributed) facility is used.

The following method is available for starting a standby system server:

• Entering the pdstart -u -s command from the unit where the system manager is defined

The specified host BES is placed in accepting status. To check whether the server is the running system, use the pdls -d ha command.

Figure 26-105 Example of starting a standby system server when the standby-less system switchover (effects distributed) facility is used

The figure below shows an example of a guest server status change when the standby-less system switchover (effects distributed) facility is used.

The following method is available to place a unit's guest server in accepting status:

• Entering the pdstart -u -s command from the unit where the system manager is defined

The specified guest BES is placed in accepting status.

Figure 26-106 Status change example of a guest server when the standby-less system switchover (effects distributed) facility is used

(b) Notes

Common notes

• When executing the pdstart -q command, you must start all backend servers within 20 minutes from the time the first backend server starts. If all backend servers cannot be started within 20 minutes, HiRDB startup processing terminates. Note that this value of 20 minutes for the startup time limit can be modified with the pd_reduced_check_time operand. The value of 20 minutes is the default for this operand.
• The -i option, -r option, and dbdestroy option cannot be specified when the pdstart command is executed in the HiRDB on a standby system.
• Activate the shared resources before executing the pdstart -r or pdstart -R command. When the server mode system switchover facility based on HA Monitor is used, you can activate the shared resources simultaneously with HiRDB startup by executing the pdstart -r -t or pdstart -R -t command. The shared resources to be activated here are the shared disk, IP addresses, and other resources defined in the server definition file of HA Monitor.
• Terminate both the running system HiRDB and standby system HiRDB before executing the pdstart -r or pdstart -R command. If HiRDB is started using the pdstart -r or pdstart -R command, HiRDB will not become a system switchover target. After a process such as database recovery processing terminates, terminate HiRDB, and then start it on the running system and standby system.

Notes on using MC/ServiceGuard

• When starting HiRDB, the MC/ServiceGuard package must have started normally on the running system. Therefore, before starting HiRDB, confirm that the package has started. Use an MC/ServiceGuard command to confirm that the package has started or to start a package.
• When the running system unit has stopped (including when the unit terminates abnormally), MC/ServiceGuard might recognize that node as one that cannot be switched during a system switchover. In such a case, that node cannot be switched even if HiRDB is waiting. Use an MC/ServiceGuard command to place that node in system switchable status.

Notes on using Hitachi HA Toolkit Extension

If HiRDB is started without activating the service process for Hitachi HA Toolkit Extension, both systems will start as standby systems. If this happens, perform the procedure in the following table.

Table 26-60 Procedure to perform when HiRDB is started without activating the service process for Hitachi HA Toolkit Extension

Condition	Procedure
Unit for which the standby-less system switchover (effects distributed) facility is applied	Servers in both the running system and the standby system are placed in standby status and can be operated by the user. Neither system is terminated abnormally. In this case, you can activate the cluster software on the host on which the server becomes the running system and complete the startup process (start the service process of HA Toolkit Extension).

Notes on using HA Monitor

Before you start the running system unit, use HA Monitor's monshow command to make sure that the standby system unit has stopped. The monshow command does not display any inactive system. If the command displays the status of the standby system, the standby system unit has not stopped.

An attempt to start the running system unit immediately after its termination might result in output of the KFPS01878-I and KFPS00715-E messages, because the standby system unit is still engaged in termination processing. If an attempt to start the running system unit has failed, perform the following procedure to start the unit:

1. Use HA Monitor's monshow command to make sure that the standby system unit has stopped.
2. Execute the pdrpause command to restart the process server process.
3. Use the pdstart command to start the running system unit.

(a) Terminating both the running system and the standby system

This subsection explains how to terminate both the running system and the standby system.

Stopping the entire system

The following table describes how to stop the entire system when the standby-less system switchover (effects distributed) facility is used.

Table 26-61 Stopping the entire system when the standby-less system switchover (effects distributed) facility is used

Input location	Command	Option	Condition	Operation
		-f	Forcibly/abnormally terminated server?
Unit where system manager is defined	pdstop	No	Yes#1	Error (a message, such as KFPS05063-E) is output.
		No	No#2	Stops the system.
		Yes	Yes	Forcibly stops the system (some units are already stopped).
		Yes	No	Forcibly stops the system.

#1

Even if a server has been forcibly or abnormally terminated, it is not considered to be a forcibly or abnormally terminated server if it is in one of the following statuses:

• Restarted at another unit and currently running
• Restarted at another unit and has already been stopped normally

#2

No under Forcibly/abnormally terminated server? means one of the following:

• There are no servers in the system that was forcibly or abnormally terminated.
• There is a server in the system that was forcibly or abnormally terminated, but it has since been restarted at another unit and is currently running.
• There is a server in the system that was forcibly or abnormally terminated, but it has since been restarted at another unit and has already been stopped normally.

The following table describes the processing that occurs during system termination.

Table 26-62 Processing that occurs during system termination

Target	Processing detail
Unit	While the system is being stopped, the system manager stops all units (by executing pdstop -u UID (-f) or its equivalent).
Server	When a unit is stopped while the system is being stopped, the system stops all host BESs and guest BESs at that unit (by executing pdstop -q -s server-name (-f) or its equivalent).

When the system is stopped, the accepting status for guest BESs at an accepting unit is canceled automatically, regardless of whether the system is being terminated forcibly or normally. This cancellation occurs, even if a guest BES is active. For this reason, you need not take any action with regard to guest BESs.

The following table describes the processing for the various back-end servers during system termination when the standby-less system switchover (effects distributed) facility is used.

Table 26-63 Processing that occurs for the various back-end servers during system termination when the standby-less system switchover (effects distributed) facility is used

Back-end server's status		Processing
Host BES	Running	Stops.
	Accepting status	Cancels the accepting status automatically.
Guest BES	Running	Stops automatically.
	Accepting status	Cancels the accepting status automatically.

The figure below shows an example of system termination. In this example, stopping the system stops the following servers:

• Host BESs
• Guest BES that is running (Automatic stop 1 in the figure)

Additionally, the accepting status for the following servers is canceled:

• Guest BESs that are in accepting status (Automatic status change 1 in the figure)
  

  Figure 26-107 System termination example

  

Stopping a unit

The following table describes how to stop a unit when the standby-less system switchover (effects distributed) facility is used.

Table 26-64 Stopping a unit when the standby-less system switchover (effects distributed) facility is used

Input location	Command	Option			Operation
		-z	-u	-f
Unit where system manager is defined	pdstop	No	Yes	No	Stops the target unit normally.
				Yes	Forcibly stops the target unit.
Target unit	pdstop	Yes	No	No	Forcibly stops the target unit.

To stop a unit, stop all host BESs and guest BESs at the unit (by executing pdstop -q -s server-name (-f) or its equivalent).

The table below indicates whether a unit can be stopped normally, depending on the status of servers in the unit. When the standby-less system switchover (effects distributed) facility is used, a unit can be stopped normally, regardless of whether any of its servers, host BESs or guest BESs, have stopped abnormally by themselves or have been forcibly stopped.

Table 26-65 Whether a unit can be stopped normally depending on the status of servers in the unit

Server status (both BESs and guest BESs)			Can the unit be stopped normally?
Starting/stopping#1	On standby	Stopped#2	Standby-less system switchover (effects distributed) facility
No	No	No	Yes
		Yes	Yes
	Yes	No	Yes
		Yes	Yes
Yes	No	No	No
		Yes	No
	Yes	No	No
		Yes	No

Legend:

Yes: The unit can be stopped normally.

No: The unit cannot be stopped normally.

#1

Includes starting normally, restarting, stopping normally, stopping according to plan, being forcibly stopped, or being stopped abnormally.

#2

Includes stopped normally, stopped according to plan, forcibly stopped, stopped abnormally, or guest area that has become unallocated after guest BES was stopped.

The following table describes the processing for the various back-end servers during unit termination when the standby-less system switchover (effects distributed) facility is being used.

Table 26-66 Processing that occurs for the various back-end servers during unit termination when the standby-less system switchover (effects distributed) facility is used

Running location	Back-end server status	Processing
Unit being stopped	Running	Stops.
	Accepting status	Cancels the accepting status.
Other unit	Running	No change.
	Accepting status	Cancels the accepting status automatically.

Example 1: Stopping a unit during normal operation

The following figure shows an example of stopping a unit during normal operation.

Figure 26-108 Example of stopping a unit during normal operation

When a unit that has not accepted any guest BESs is stopped, the following servers are also stopped:

• The host BESs in the unit

In addition, the accepting status is canceled for the following servers:

• The guest BESs in the unit that are in accepting status (Cancellation of accepting status)
• The guest BESs in other units that correspond to the host BESs in the unit being stopped (Automatic cancellation of accepting status)

Example 2: Stopping a unit that has accepted a guest BES

The following figure shows an example of stopping a unit that has accepted a guest BES.

Figure 26-109 Example of stopping a unit that has accepted a guest BES

When a unit that has accepted a guest BES is stopped, the following servers are also stopped:

• The host BESs in the unit
• The guest BESs that are running in the unit (Automatic stop 1)
• The host BESs in other units that correspond to the guest BESs that are running in the unit that is being stopped (Automatic stop 2)

In addition, the accepting status is canceled for the following servers:

• The guest BESs in the unit that are in accepting status (Cancellation of accepting status)
• The guest BESs in other units that correspond to the host BESs in the unit being stopped (Automatic cancellation of accepting status)
• The guest BESs in other units that correspond to the guest BESs that are running in the unit being stopped (Automatic cancellation of accepting status)

Example 3: Stopping a unit that has only a guest BES

The following figure shows an example of stopping a unit in which only a guest BES is running.

Figure 26-110 Example of stopping a unit in which only a guest BES is running

When a unit in which only a guest BES is running is stopped, the following servers are also stopped:

• The host BESs in the unit
• The guest BES in the unit that is running (Automatic stop 1)
• The host BESs in other units that correspond to the guest BES that is running in the unit that is being stopped (Automatic stop 2)

In addition, the accepting status is canceled for the following servers:

• The guest BESs in the unit that are in accepting status (Cancellation of accepting status)
• The guest BESs in other units that correspond to the guest BES that is running in the unit being stopped (Accepting status canceled automatically)

Stopping a server

The following table describes how to stop a server when the standby-less system switchover (effects distributed) facility is being used.

Table 26-67 Stopping a server when the standby-less system switchover (effects distributed) facility is used

Input location	Command	Option				Operation
		-z	-u	-s	-f
Unit where system manager is defined	pdstop	No	No	Yes	No	Stops the target server#2.
					Yes	Forcibly terminates the target servers in all active units in the HA group#1.
			Yes	Yes	No	Stops the target server#2, #3.
					Yes	Forcibly stops the target server#2
Target unit	pdstop	Yes	No	Yes	No	Forcibly stops the target server (host BES)#4.

#1

Of all the active units in the HA group, servers in the running system units only are stopped. The accepting status is canceled for other units.

#2

If pdstop -s(f) is used to stop a running server, the accepting status is canceled automatically for all active units in the HA group.

#3

Table 26-68 Server termination results depending on the server status shows the results of server termination depending on the server status.

#4

For Hitachi HA Toolkit Extension, even when pdstop -z -s is used to stop the running server, the accepting status for the server is not canceled automatically at other units in the HA group. To cancel the accepting status, enter Hitachi HA Toolkit Extension's standby stop command (hatesbystp) at all units in the HA group.

Table 26-68 Server termination results depending on the server status

Server status	Start result
Waiting for the running system to start	Cancels the wait for the running system to start.
Accepting status	Cancels the accepting status.
Active	Stops the server.

The following table describes the processing for the various back-end servers during server termination when the standby-less system switchover (effects distributed) facility is used.

Table 26-69 Processing that occurs for the various back-end servers during server termination when the standby-less system switchover (effects distributed) facility is used

Running location	Back-end server status	Processing
Active unit	Operation target	Stops.
Other units	Accepting status	Cancels the accepting status.

Example 1: Stopping a host BES

The following figure shows an example of stopping a host BES.

Figure 26-111 Example of stopping a host BES

When a host BES is stopped, the following server is also stopped:

• The host BES

In addition, the accepting status is canceled for the following servers:

• The guest BESs in other units that correspond to the host BES in the unit being stopped (Cancellation of accepting status)

Example 2: Stopping a guest BES

The following figure shows an example of stopping a guest BES.

Figure 26-112 Example of stopping a guest BES

When a guest BES is stopped, the following servers are also stopped:

• The running guest BES
• The host BESs in other units that correspond to the running guest BES that is being stopped (Automatic stop)

In addition, the accepting status is canceled for the following servers:

• The guest BESs in other units that correspond to the running guest BES that is being stopped (Cancellation of accepting status)

(b) Stopping only the back-end server of the standby system

This subsection explains how to stop only the standby system.

As when using the standby system switchover facility or the standby-less system switchover (1:1) facility, the monsbystp command of HA Monitor can be used to stop the standby system. When the standby-less system switchover (effects distributed) facility is used, you can also perform the operation from the unit where the system manager is defined.

The following table describes how to terminate the standby system when the standby-less system switchover (effects distributed) facility is used.

Table 26-70 Terminating the standby system when the standby-less system switchover (effects distributed) facility is used

Input location	Command	Operation target	Operation
Host where the operation-target server is located	monsbystp#	Back-end server in accepting status	Cancels the accepting status for a guest BES.
Unit where system manager is defined	pdstop -u -s

#

Use the hatesbystp command if you are using Hitachi HA Toolkit Extension.

Example 1: Example of canceling the accepting status for a guest BES

The following figure shows an example of canceling the accepting status for a guest BES.

Figure 26-113 Example of canceling the accepting status for a guest BES

To cancel the accepting status for a guest BES, enter HA Monitor's monsbystp command. If you are using Hitachi HA Toolkit Extension, enter the hatesbystp command.

Example 2: Example of stopping a host BES of the standby system

The following figure shows an example of stopping a host BES of the standby system.

Figure 26-114 Example of stopping a host BES of the standby system

To stop a host BES of the standby system, enter HA Monitor's monsbystp command. If you are using Hitachi HA Toolkit Extension, enter the hatesbystp command.

(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-71 Checking the operating status of units and servers when a system switchover facility is used

Command	Output information
pdls -d svr	Host name (the host name of the accepting unit is displayed after a system switchover) Unit operating status (the unit identifier of the accepting unit is displayed after a system switchover) Server operating status (displayed as a server belonging to the accepting unit after a system switchover)

(b) Checking the system status

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

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

Command	Output information
pdls -d ha	Name and status of the unit where the back-end server is located (running/standby/stopped/running system in waiting status) and defined destination unit name Detailed status of the back-end server is displayed only when the detailed display option (-a) is specified.
monshow (only when HA Monitor is used)	Host name and status of the local system#1 Host name and status of the other system#2
hateshow (only when Hitachi HA Toolkit Extension is used)	Status of the local system#3

#1: Statuses are displayed for the following categories:

Executing, on standby, starting as a running server, starting as a standby server, stopping as a running server, stopping as a standby server, waiting for restart as a running server, waiting for restart as a standby server, waiting for server system switchover, waiting for linked server system switchover

#2: Statuses are displayed for the following categories:

Executing, on standby, starting as a running server, starting as a standby server, stopping as a running server, stopping as a standby server, waiting for restart as a running server

#3: Statuses are displayed for the following categories:

Running server startup completed, standby server startup completed, running server starting, standby server starting, running server stopping, standby server stopping, running server waiting for restart wait, server not started

The statistics log files are the two files pdstj1 and pdstj2. These files are created as a set for the primary HiRDB system. Because the accepting unit's statistics log files are shared at the switching destination, no files are created for the secondary system. The HiRDB administrator must prepare files for the regular unit and for the accepting unit.

(a) Creating unload statistics log files

When a system switchover occurs, the statistics log files to be used by the switching-destination host are the files being used by the accepting unit at the switching destination. Because statistics log output destination files are distributed to each host, unload statistics log files must be created on a specific server machine.

Unload statistics log files are created at the following times:

• 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-less system switchover (effects distributed)).

Figure 26-115 Examples of unload statistics log files created when a system switchover facility is used (standby-less system switchover (effects distributed))

Hint

Because statistics log files have identical names on all server machines, do not use the same names when you create the unload statistics log files. 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.

When a system switchover occurs, statistics log files are handled by the switching-destination host.

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

When a system switchover occurs, the statistics log collection status that existed immediately before the system switchover is inherited. That is, if statistics logs were being collected before the system switchover, statistics logs will continue to be collected at the switched server after the system switchover, regardless of the value specified in the pd_statistics operand of the system common definition. In this case, the statistics log files are shared with the accepting unit at the switching destination. If statistics logs were not being collected immediately before the system switchover, no statistics logs will be collected after the system switchover. You can begin collecting statistics logs by entering the pdstbegin command after switchover.

The following table indicates whether statistics logs are collected when the standby-less system switchover (effects distributed) facility is used.

Table 26-73 Statistics log collection when the standby-less system switchover (effects distributed) facility is used

Unit type	Whether logs were collected	Accepting unit
Regular unit	Logs were being collected.	Collects logs.
	Logs were not being collected.	Does not collect logs.

The following figure shows an example of statistics log collection after a system switchover when the standby-less system switchover (effects distributed) facility is used.

Figure 26-116 Example of statistics log collection after a system switchover when the standby-less system switchover (effects distributed) facility is used

(c) Executing the statistics analysis utility

The statistics analysis utility is executed using the unload statistics log files created at the regular unit and the accepting unit as the input information. To manually copy the files that existed prior to a system switchover you must use, for example, an OS command. The statistics information on the server that was switched is processed as information on a server belonging to the accepting unit.

If a system switchover occurs because of 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.