• Install and set up the environment for the following products:
  
  • HiRDB Advanced High Availability (for all server machines)
  • Hitachi HA Toolkit Extension (for normal and alternate units). Note that this installation is not necessary when the cluster software product being used is HA Monitor.
• The standby-less system switchover (effects distributed) facility can be applied to a unit that is configured using only back-end servers.
• There is no need to provide a HiRDB directory for a guest BES.
  Because the standby-less system switchover (effects distributed) facility uses the HiRDB directory of an accepting unit, there is no need to provide HiRDB directories specifically for the guest BESs. That is, the pdsetup command is not necessary for a guest BES.
  
• Allocate system definition files.
  In each unit comprising the group, allocate a back-end server definition file to each back-end server in the HA group. The parameters to be set in the unit control information definition as the default values for back-end server definitions must be defined in the system common definition or a back-end server definition file.
  

There must be an external hard disk that can be shared between the primary system and the secondary system (or between the host BES and the guest BES). This hard disk is called a shared disk unit.

(a) Shared disk allocation

The following figure shows shared disk allocation.

Figure 26-82 Shared disk allocation

Explanation

A shared disk is allocated to each server because a system switchover occurs on a server-by-server basis. You cannot store information from multiple servers on a single shared disk.

Create the following HiRDB file system areas on the shared disk unit:

• HiRDB file system area for RDAREAs
• HiRDB file system area for system files
• HiRDB file system area for backup files
• HiRDB file system area for unload log files

Notes

• Set up these HiRDB file system areas so that the HiRDBs of both the primary system and the secondary system can reference the shared disk unit by using the same path name. Additionally, set up all units in the HA group so that they can reference the shared disk unit by using the same path name. However, create the unit status file in an independent, non-shared disk that is different from those used for server status files, system log files, and synchronization point dump files.
• The shared disk on which HiRDB file system areas for shared RDAREAs are created must be activated in the write mode from all units. For this reason, the disk must not be deactivated or activated in conjunction with a system switchover.
• On a shared disk, use character special files instead of regular files. If a system switchover occurs when regular files are in a status that does not apply to shared disks (for example, data remains in the operating system cache even though HiRDB finished writing it to the target files), any updates made to the files might be lost. Note that if the operating system can guarantee the integrity of the data in regular files (journal file systems) even if a system switchover occurs, the following files can be used on a shared disk:
  Unload log files that are unloaded using the pdlogunld command or the automatic log unloading facility
  Backup files that are acquired using the database copy utility (pdcopy)
  Unload data files that are created using the database reorganization utility (pdrorg)
  

(b) Shared disk access control

If the system switchover source and target both attempt to access the shared disk at the same time while the system switchover facility is being used, the database might become corrupted. For this reason, accesses from the system to the shared disk must be controlled. This shared disk access control is performed by the cluster software or HiRDB.

Normally, the method described in Shared disk access control by the cluster software is used to perform access control on the shared disk. To use the method described in Shared disk access control by HiRDB, you must have HA Monitor 01-08 or later.

Shared disk access control by cluster software

The cluster software performs access control on the shared disk. It exercises control in such a manner that the running system is active and the standby and stopped systems are inactive, so that only the running system can access the shared disk. The following figure shows shared disk access control by the cluster software.

Figure 26-83 Shared disk access control by the cluster software

Explanation

An inactive system cannot access the shared disk. Only the running system can access the shared disk.

For details about the shared disk switching method (between active and inactive), see the cluster software documentation.

If you are using HA Monitor, you must specify the disk operand in the servers definition statement for HA Monitor.

Shared disk access control by HiRDB

To use HiRDB to perform access control on the shared disk, you must have HA Monitor 01-08 or later.

HiRDB can perform access control on the shared disk. In this case, shared disk switching (between active and inactive) is not performed. System switchovers take place in the following sequence:

1. A failure that triggers a system switchover occurs.
2. HiRDB confirms that all processes (HiRDB processes) have terminated in the source system.
3. The system switchover takes place.
4. The target system starts accessing the shared disk.

The following figure shows the shared disk access control that is provided by HiRDB.

Figure 26-84 Shared disk access control by HiRDB

• Criteria
  Use HiRDB to perform shared disk access control in the following cases:
  
  • When Linux is being used
    Character special files on an LVM are not supported in the Linux edition, but an LVM is required by a shared disk whose access is to be controlled by HA Monitor. For this reason, you cannot use the method described in Shared disk access control by the cluster software.
    If Linux AS 4 or Linux ES 4 or later is used, character special files on an LVM can be used, which allows cluster software to be used to control the access to the shared disk.
    
  • When shared RDAREAs are used
    When shared RDAREAs are used, the shared disk that contains a shared RDAREA must be made active from all server machines where a back-end server is located. If an updatable back-end server and a reference-only back-end server are both located on the same server machine, the updatable back-end server becomes the target of any system switchover that occurs. If shared disk switching occurs in such a case, the shared RDAREA can no longer be referenced from the reference-only back-end server. Therefore, you cannot use the method described in Shared disk access control by the cluster software.
    
  • When Real Time SAN Replication is used in the log-only synchronous method
    When Real Time SAN Replication is used in the log-only synchronous method, TrueCopy is used at the log application site to copy system files from a remote location. When TrueCopy is used, LVM cannot be used, but LVM is required for a shared disk whose access is to be controlled by HA Monitor. For this reason, you cannot use the method described in Shared disk access control by the cluster software.
    
• HiRDB environment settings
  You must specify the following operands in the HiRDB system definition:
  
  • pd_ha_prc_cleanup_check = Y
    When Y is specified in this operand, system switchovers take place only after all processes have terminated in the unit. With the standby-less system switchover (effects distributed) facility, system switchovers take place after all processes have terminated at the back-end servers.
    
  • pd_ha_switch_timeout = Y
    At times, a system switchover cannot be performed because, due to ongoing disk I/O processing or some other reason, a server process has not terminated. When Y is specified in this operand, HA Monitor treats it as a server (HiRDB) slowdown and resets the system, so that the system switchover can take place.
    
• HA Monitor environment settings
  Specify operands in the servers definition statement for HA Monitor as follows:
  
  • pairdown
    You must specify use:serv_slow in this operand.
    There are times when you cannot confirm whether a server process has terminated, such as when a server process does not terminate at the source system or when HiRDB slows down. Such an event prevents any system switchover from being performed. When this operand is specified, the system is reset to allow execution of a system switchover when termination of processes cannot be confirmed for a reason such as a slowdown.
    
  • disk
    Omit this operand because HA Monitor does not perform access control on the shared disk.
    

(a) Configuring HiRDB system definition files

The following table explains how to use system definition files when the standby-less system switchover (effects distributed) facility is used.

Table 26-22 Use of system definition files when the standby-less system switchover (effects distributed) facility is used

#

If you are placing multiple units on the same server machine, specify in this operand a different value for each unit.

(b) HiRDB system definition operands to be set up when the standby-less system switchover (effects distributed) facility is used

This subsection explains the HiRDB system definition operands that you need to set up when the standby-less system switchover (effects distributed) facility is used. The following table lists the related operands.

Table 26-23 HiRDB system definition operands to be set up when the standby-less system switchover (effects distributed) facility is used

(c) Specifying the switching destination

When the standby-less system switchover (effects distributed) facility is used, the method of determining the switching destination differs significantly from when the other system switchover facilities are used.

Accepting unit

Because the standby-less system switchover (effects distributed) facility switches systems on a server-by-server basis, a switching destination must be specified for each server. You can specify multiple accepting units for a server. Multiple accepting units are defined as an HA group, so you must specify an HA group as the switching destination for each server.

When you use the standby-less system switchover (effects distributed) facility, you can also specify the maximum number of guest BESs that will be permitted to run concurrently in each unit (pd_ha_max_act_guest_servers).

Figure 26-85 HA group configuration (1) and Figure 26-86 HA group configuration (2) show HA group configurations,

Figure 26-85 HA group configuration (1)

pdhagroup -g hag1 -u unt1,unt2,unt3,unt4 pdstart -t BES -s bes1A -u unt1 -g hag1 pdstart -t BES -s bes1B -u unt1 -g hag1 pdstart -t BES -s bes1C -u unt1 -g hag1 pdstart -t BES -s bes2A -u unt2 -g hag1 pdstart -t BES -s bes2B -u unt2 -g hag1 pdstart -t BES -s bes2C -u unt2 -g hag1 pdstart -t BES -s bes2D -u unt2 -g hag1 pdstart -t BES -s bes3A -u unt3 -g hag1 pdstart -t BES -s bes3B -u unt3 -g hag1 pdstart -t BES -s bes3C -u unt3 -g hag1 pdstart -t BES -s bes4A -u unt4 -g hag1 pdstart -t BES -s bes4B -u unt4 -g hag1

Figure 26-86 HA group configuration (2)

pdhagroup -g hag1 -u unt1,unt2 pdhagroup -g hag2 -u unt3,unt4 pdstart -t BES -s bes1A -u unt1 -g hag1 pdstart -t BES -s bes1B -u unt1 -g hag1 pdstart -t BES -s bes1C -u unt1 -g hag1 pdstart -t BES -s bes2A -u unt2 -g hag1 pdstart -t BES -s bes2B -u unt2 -g hag1 pdstart -t BES -s bes2C -u unt2 -g hag1 pdstart -t BES -s bes2D -u unt2 -g hag1 pdstart -t BES -s bes3A -u unt3 -g hag2 pdstart -t BES -s bes3B -u unt3 -g hag2 pdstart -t BES -s bes3C -u unt3 -g hag2 pdstart -t BES -s bes4A -u unt4 -g hag2 pdstart -t BES -s bes4B -u unt4 -g hag2

HA group definition

You use the HiRDB system definition to define an HA group. Specify a name for the HA group in the -g option of the pdhagroup operand, and specify in the -u option the unit identifiers of the units that are to comprise the HA group.

Example

pdhagroup -g hag1 -u unt1,unt2 ...1. pdhagroup -g hag2 -u unt3,unt4 ...2.

1. Defines HA group hag1 consisting of unt1 and unt2.
2. Defines HA group hag2 consisting of unt3 and unt4.

The following restrictions apply to HA groups:

• A maximum of 32 units can be defined in an HA group.
• All units in an HA group must be allocated in the same network segment.
• The maximum total number of host BESs and guest BES areas (which is the maximum active guest BESs) that can be defined in a unit within an HA group is 34.

Each unit comprising an HA group must satisfy all of the following conditions:

1. A unit that contains no host BES (an accepting-only unit) cannot belong to an HA group.
2. Each unit belonging to an HA group must contain at least one host BES.
3. All servers that comprise a unit belonging to an HA group must be back-end servers. An HA group unit cannot contain any server whose server type is other than BES.
4. The only type of system switchover that can be used for units belonging to an HA group is standby-less system switchover (effects distributed). This means that for units belonging to an HA group, the only value that can be specified in the pd_ha_agent operand is activeunits.
5. A unit can belong only to a single HA group.

Specifying an accepting unit

In the HiRDB system definition, you specify in the -g option of the pdstart command the HA group to which an accepting unit belongs.

You must specify the -g option for all servers that belong to a unit to which standby-less system switchover (effects distributed) processing is applicable.

Example: pdstart -t BES -s bes1A -u unt1 -g hag1

When unt1 or bes1 terminates abnormally, processing for bes1 can be accepted by a unit belonging to the HA group named hag1.

Note the following points about specifying the -g option:

1. Both the regular unit and the accepting unit must be comprised exclusively of back-end servers.
   BES must be specified in the -t option.
   Each unit belonging to the HA group specified by the -g option must only contain servers whose server type is BES.
   
2. The number of servers comprising a regular unit need not be the same as the number of servers comprising an accepting unit.
   The number of servers in the unit specified by the -u option (regular unit) need not be the same as the number of servers in the unit belonging to the HA group specified by the -g option (accepting unit).
   

Specifying the maximum number of concurrently running guest BESs

You can specify in the pd_ha_max_act_guest_servers operand of the unit control information definition the maximum number of guest BESs that are permitted to operate concurrently as running systems in a unit. The purpose of this specification is to reduce the amount of resources required by guest BESs. It can also prevent excessive increases in workload.

Example: pd_ha_max_act_guest_servers = 2

The maximum value that can be specified in the pd_ha_max_act_guest_servers operand is the number obtained by subtracting the number of servers in the local unit from the number of servers in the HA group. If you specify a value greater than this maximum, the maximum value will be set in the pd_ha_max_act_guest_servers operand. The number of host BESs plus the value of the pd_ha_max_act_guest_servers operand cannot exceed 34.

The number of guest BESs that are in accepting status in a unit is not restricted. However, when the number of guest BESs that are operating as running systems in a unit reaches the value specified in the pd_ha_max_act_guest_servers operand, acceptability is canceled for all of the non-active guest BESs.

Once the number of BESs with errors in an HA group exceeds the combined total number of free guest areas in the running system units in the HA group, any subsequent error will cause some servers to stop, and their processing will be suspended.

(d) Server process allocation after a system switchover

Even after an effects-distributed standby-less system switchover occurs, an accepting unit can continue to accept guest servers until the number of running guest servers reaches the value of the pd_ha_max_act_guest_servers operand.

At the accepting unit, the host BES and guest BES start server processes within their respective maximum number of active processes (value of the pd_max_bes_process operand). However, the combined total number of server processes in other units is limited to the value specified for the pd_ha_max_server_process operand. This prevents an excessive increase in workload at the accepting unit. However, you need to be aware that there might be an upper limit to the number of service requests that can be processed concurrently after a system switchover. For this reason, when you set the pd_ha_max_server_process operand, take into consideration both the increase in the unit's workload following a system switchover and the number of service requests that can be processed concurrently.

If the number of resident processes (value of the pd_process_count operand) on the host BES has some margin before a system switchover, and if server processes not currently processing service requests are resident, those server processes not currently processing service requests can be used to handle the guest BES's processes following a system switchover. As a result, processing performance improves. However, if the number of resident processes is increased unnecessarily, processes handling non-service requests can cause the number of server processes to reach the value of the pd_ha_max_server_process operand. Consequently, additional service requests might not be processed in some cases even if the number of server processes already started on other servers has not reached the value of the pd_max_bes_process operand. It is advisable to set the ratio between the total number of resident processes in the units and the total of the maximum number of running processes to remain the same before and after guest servers are accepted. In this way, the total number of resident processes in the units after guest servers are accepted is restricted by the pd_ha_process_count operand. The actual number of resident processes will be either the number obtained by proportionally allocating the value of the pd_ha_process_count operand based on the values of the pd_process_count operands of the servers that are running in the unit, or the actual value of the pd_process_count operand, whichever is smaller.

The following explains the meaning of each operand that is related to the number of processes:

• pd_ha_max_act_guest_servers: Number of guest BESs that can be accepted (maximum number in accepting status)
• pd_ha_max_server_process: Maximum number of running processes, for both guest BESs and host BESs
• pd_ha_process_count: Maximum number of resident processes, for both guest BESs and host BESs

The following figure shows the allocation of server processes following an effects-distributed standby-less system switchover (1/2).

Figure 26-87 Allocation of server processes following an effects-distributed standby-less system switchover (1/2)

Before a system switchover occurs, each host BES (bes1 and bes2) can execute concurrently as many processes as the value of its pd_max_bes_process operand. For each host BES, as many server processes as the value of its pd_process_count operand can also be made resident.

When a system switchover occurs, the resident processes of the host BESs (bes1, bes2) are used to prepare the server process of the guest BES (bes3). Therefore, there is no need to start the server process of the guest BES (bes3), and processing for the guest BES (bes3) can begin immediately following the switchover. Also, there is no need to keep a server process for the guest BES (bes3) on standby before a switchover.

Each server starts back-end servers as needed up to the value of its pd_max_bes_process operand, but the total number of server processes in a unit is limited to the value of the pd_ha_max_server_process operand.

Also, the number of resident processes in each server is adjusted so that the combined total number of resident processes in the units equals the value of the pd_ha_process_count operand. The value of the pd_ha_process_count operand is allocated among the servers so that the number of resident processes for each server after adjustment maintains the ratio determined by each server's pd_process_count operand value.

The following figure shows the allocation of server processes following an effects-distributed standby-less system switchover (2/2).

Figure 26-88 Allocation of server processes following an effects-distributed standby-less system switchover (2/2)

Following a system switchover, while the guest BES (bes3) is being accepted, the back-end servers of the host BESs (bes1, bes2) and the guest BES (bes3) are started as needed. However, the number of back-end servers in the unit cannot exceed the value specified for the pd_ha_max_server_process operand.

If the number of processing requests to a particular host BES (bes1, for example) is especially large, processes can be executed concurrently up to the value of the pd_max_bes_process operand of that host BES (bes1). However, the number of processing requests that can be handled by other servers (bes3, for example) decreases accordingly.

Define RDAREAs in HiRDB file system areas for RDAREAs on the shared disk. This subsection provides definition examples of creating user RDAREAs and system RDAREAs in HiRDB file system areas that are created on different shared disks. It also explains these concepts based on the system configuration examples shown in the following figure.

Figure 26-89 HiRDB single server configuration example

Example of create rdarea statement specification

 
create rdarea PMAST for masterdirectory                      1
    server name DIC file name "/dic0111/prd01"
    initial 10 segments;
create rdarea PDIR for datadirectory                         2
    server name DIC file name "/dic0112/prd02"
    initial 5 segments;
create rdarea PDIC for datadictionary                        3
    server name DIC file name "/dic0113/prd03"
    initial 20 segments;
create rdarea PUSR01 for user used by PUBLIC                 4
    server name BACK01 file name "/back0121/prd04"
    initial 500 segments;
create rdarea PUSR02 for user used by PUBLIC                 5
    server name BACK02 file name "/back0231/prd05"
    initial 500 segments;
 

Explanation

1. Creates the PMAST master directory RDAREA in the HiRDB file system area on shared disk A.
2. Creates the PDIR data directory RDAREA in the HiRDB file system area on shared disk A.
3. Creates the PDIC data dictionary RDAREA in the HiRDB file system area on shared disk A.
4. Creates the PUSR01 user RDAREA in the HiRDB file system area on shared disk B.
5. Creates the PUSR02 user RDAREA in the HiRDB file system area on shared disk C.

When you use the standby-less system switchover (effects distributed) facility, you can allocate global buffers on a unit-by-unit basis.

To allocate a global buffer to RDAREAs or indexes located in back-end servers to which the standby-less system switchover (effects distributed) facility is applicable, specify the -c option (sharing option) in the pdbuffer operand. A global buffer allocated by specifying the -c option is called a unit-based global buffer. The unit-based global buffers have the following characteristics:

• Unit-based global buffers must be allocated to all units comprising an HA group.
• If the RDAREAs and indexes to which the same unit-based global buffer is to be allocated are located in multiple back-end servers, their global buffer resources are divided and used evenly among the multiple back-end servers. If these resources are located in a single back-end server, they are used exclusively by that back-end server. If a global buffer defined with the -o option specified is allocated to RDAREAs located in multiple back-end servers, the global buffer resources are also divided and used evenly among the multiple back-end servers. The figure below shows an example of the concept of sharing a unit-based global buffer. In this figure, the same unit-based global buffer is allocated to servers in different units.
  

  Figure 26-90 Sharing of a unit-based global buffer

  

  pdbuffer -a bp01 -r RD11,RD12 -n 60 -c

(a) Design concepts for a unit-based global buffer

First, select whether the global buffer is to be shared. You can design a global buffer for reduced operation after a system switchover occurs based on either of the following concepts:

1. Sharing design
   During reduced operation, memory is used efficiently by means of sharing the accepting unit's global buffer. This is called a sharing design, and it has the following characteristics:
   
   • Advantage: Because the accepting unit's global buffer is shared during reduced operation, memory usage efficiency is high.
   • Disadvantage: During reduced operation, the buffer hit rate is reduced proportionately to the number of servers that share the global buffer.
2. Non-sharing design
   Global buffer resources to be used only during reduced operation are allocated to each accepting unit and go into service when a system switchover occurs. This is called a non-sharing design. It has the following characteristics:
   
   • Advantage: Because the same amount of buffer resources are available for use before and during reduced operation, the hit rate can be maintained.
   • Disadvantage: Because global buffer resources to be used only during reduced operation are allocated to an accepting unit, memory usage efficiency is low.

Because the objective of the standby-less system switchover (effects distributed) facility is to share resources and distribute the workload, it is more advantageous to use the sharing design (1 above), because memory is used more efficiently.

With a non-sharing design, global buffers dedicated to the servers are allocated to all accepting units. Therefore, for an entire HA group, you can estimate the required amount of shared memory for global buffers by multiplying the estimated amount of shared memory for normal global buffers by the number of units comprising the HA group. If the amount of shared memory available satisfies the estimate, performance can be maintained even during reduced operation, enabling you to use a non-sharing design (2 above).

Procedure for sharing design

The following procedure explains how to create a sharing design in which a global buffer is shared:

1. Determine the RDAREAs that share the same buffer pool.
   
   • Sharing among RDAREAs of the same type
     Use the -r option of the pdbuffer operand to specify RDAREAs of the same type, such as RDAREAs for data, index RDAREAs, or LOB RDAREAs, so that they can share global buffers. When a global buffer is shared by RDAREAs of the same size or same access frequency, memory efficiency is high.
     
   • Sharing among RDAREAs for row-partitioned tables or indexes
     Use the -r option of the pdbuffer operand to specify RDAREAs for row-partitioned tables or RDAREAs for row-partitioned indexes so that they share a global buffer. If the row-partitioned tables and indexes are stored in the same RDAREA, specify the -i option of the pdbuffer operand to allocate a buffer exclusively for indexes.
     
   Also, depending on the server and unit allocation of the RDAREAs that share a global buffer, the characteristics described below can be obtained. Use these characteristics for reference when selecting the RDAREAs that will share a global buffer.
   
   • When sharing occurs between RDAREAs of servers located in different units:
     Because global buffers can be used exclusively before reduced operation occurs, an allocation can be made that places more importance on performance before reduced operation occurs. However, global buffer resource allocation during reduced operation becomes unbalanced among units.
     
   • When sharing occurs between RDAREAs of servers located in the same unit, and an RDAREA of a server located in a different unit:
     Buffer allocation during reduced operation can be kept balanced among units.
     
2. Determine the buffer sector count of a global buffer to be shared.
   The number of buffer sectors specified with the -n option are divided equally and used among the sharing servers within the HA group. For this reason, you must specify a buffer sector count that is appropriate to the number of sharing servers so that a shortage does not occur. Use the following formula to estimate an appropriate buffer sector count:
   

   number of sectors needed by each server (number of host BESs + number of guest BESs)

If there is an RDAREA that requires the same level of performance before and during reduced operation, allocate to that RDAREA alone a server-specific global buffer. For details, see Procedure for non-sharing design.

Procedure for non-sharing design

The following explains how to create a non-sharing design that does not share global buffers.

You can allocate a server-specific global buffer either for a single RDAREA or for multiple RDAREAs belonging to the same server.

• Allocating exclusively to a single RDAREA
  Specify the RDAREA in the -r option of the pdbuffer operand. Because there is no competition from other RDAREAs, you can allocate a global buffer to maximize performance. You can also allocate an index-specific buffer by specifying a non-partitioning index in the -i option of the pdbuffer operand.
  
• Allocating to multiple RDAREAs belonging to the same server
  Specify in the -r option of the pdbuffer operand multiple RDAREAs belonging to the same server. Specify RDAREAs of the same type, such as RDAREAs for data, index RDAREAs, or LOB RDAREAs.
  

(b) Allocating global buffers for RDAREAs and LOB global buffers (-r or -b option specified)

Allocation of global buffers for RDAREAs and LOB global buffers on a unit-by-unit basis can be classified into four types, depending on the combination of the specified RDAREAs. The following table lists the recommended conditions for global buffer sharing modes (-r or -b option specified).

Table 26-24 Recommended conditions for global buffer sharing modes (-r or -b option specified)

Select the appropriate sharing mode by considering the buffer design guidelines for the -r or -b specification explained below. Because the objective of the standby-less system switchover (effects distributed) facility is to share resources and distribute the workload, it is preferable to use Sharing by servers in different units or Sharing by servers in a unit and in different units, both of which involve sharing among units. If it is important to maintain performance even during reduced operation, select Non-shared or Sharing by servers in a unit.

Buffer design guidelines for the -r or -b specification

1. For an RDAREA for which you want the buffer hit rate to be maintained even during reduced operation in an environment with ample memory, select Non-shared or Sharing by servers in a unit.
2. To have a particular server use the buffer resources exclusively during normal operation and allow sharing with other servers during reduced operation, select Sharing by servers in different units.
3. In cases other than 1 or 2, select Sharing by servers in a unit and in different units.

Allocating non-shared global buffers

Specify only RDAREAs belonging to a single back-end server in the -r or -b option of each pdbuffer operand. A system configuration example follows.

System configuration example

Global buffer definitions

 
pdbuffer -a gbuf01 -r RDAREA11,RDAREA12 -n 2000 -c
pdbuffer -a gbuf02 -r RDAREA21 -n 1000 -c
pdbuffer -a gbuf03 -r RDAREA31 -n 1000 -c
 

Explanation

Only RDAREAs belonging to a single back-end server are specified in the -r or -b option of each pdbuffer operand.

Non-shared buffers gbuf01, gbuf02, and gbuf03 are allocated to BES11, BES21, and BES31, respectively.

Even after a system switchover, gbuf01 is used exclusively by BES11, and thus the buffer hit rate does not decline. However, because a buffer to be used after the system switchover must be allocated for each accepting unit, a large amount of memory is used.

Notes

• The same global buffer is created for all accepting units. This global buffer is not used until a system switchover occurs.
• To improve memory efficiency, specify RDAREAs of the same page size.

Allocating global buffers to be shared by servers in a unit

Specify this option if you wish to maintain the same buffer performance even when multi-point errors occur during reduced operation in an environment with ample memory. Specify RDAREAs allocated to back-end servers in the same unit in the -r or -b option of each pdbuffer operand.

System configuration example

Global buffer definitions

 
pdbuffer -a gbuf01 -r RDAREA11,RDAREA12 -n 1000 -c
pdbuffer -a gbuf02 -r RDAREA21,RDAREA22 -n 1000 -c
pdbuffer -a gbuf03 -r RDAREA31,RDAREA32 -n 1000 -c
 

Explanation

RDAREAs allocated to back-end servers in the same unit are specified in the -r or -b option of each pdbuffer operand.

Global buffers gbuf01, gbuf02, and gbuf03 that are to be shared by servers in each unit are allocated.

Because gbuf01 is used even after a system switchover, the buffer hit rate does not decline. However, because a buffer to be used after the system switchover must be allocated for each accepting unit, a large amount of memory is used.

Notes

• The same global buffer is created for all accepting units. This global buffer is not used until a system switchover occurs.
• A global buffer with this specification is shared among multiple servers.
• The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified RDAREAs.

Allocating global buffers to be shared by servers in multiple units

Rather than specifying RDAREAs allocated to servers in the same unit, you can specify RDAREAs allocated to servers in different units in the -r or -b option of the pdbuffer operand.

System configuration example

Global buffer definition

 
pdbuffer -a gbuf01 -r RDAREA11,RDAREA21,RDAREA31 -n 1000 -c
 

Explanation

RDAREAs allocated to servers located in different units are specified.

A global buffer is not shared exclusively among RDAREAs allocated to servers in the same unit. Instead, a global buffer can be shared by RDAREAs allocated to servers located in different units.

Before reduced operation, the resource (buffer) can be used exclusively by BES11. During reduced operation, because the resource must be shared between BES21 and BES11, the amount of the resource (buffer) that can be used by each back-end server is halved.

Notes

• Because the switching destination is a single unit, the workload on the global buffer of that unit alone becomes high. Therefore, define multiple buffers to be shared by servers at multiple units so that the workload among individual units is balanced.
• The same global buffer is created for all accepting units.
• A global buffer with this specification is used exclusively by a single server during normal operation and is shared among multiple servers during reduced operation.
• The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified RDAREAs.

Allocating global buffers to be shared by the servers in a unit and in different units

You can specify RDAREAs to be shared by the servers in a unit and in different units in the -r or -b option of the pdbuffer operand.

System configuration example

Global buffer definition

 
pdbuffer -a gbuf01 -r RDAREA11,RDAREA12,RDAREA21,RDAREA22,RDAREA31,RDAREA32 -n 1000 -c
 

Explanation

The RDAREAs to be shared by the servers in the unit and in different units are specified in the -r or -b option of the pdbuffer operand.

Because the global buffer is shared among RDAREAs that are shared by servers in different units, this method of buffer allocation results in a balanced workload during reduced operation. During normal operation, the back-end servers in each unit share that unit's gbuf01, and the amount of each buffer's resources allocated to each back-end server is one half of the total. During reduced operation, the three back-end servers share gbuf01, so the amount of buffer resources allocated to the back-end servers in each unit is one-third of the total.

Notes

• Design the configuration so that the number of servers to be supported during reduced operation is equalized among the individual accepting units.
• The same global buffer is created for all accepting units.
• A global buffer with this specification is shared by multiple servers.
• The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified RDAREAs.

(c) Allocating a global buffer to an index (-i option specified)

To buffer the index pages of a particular index, allocate a global buffer for the index. If an index RDAREA contains only an index, you can also achieve the same effect by allocating a global buffer for an RDAREA (-r option specified) to that RDAREA. Allocation of global buffers to indexes on a unit-by-unit basis can be classified into four types depending on the allocation of the index RDAREA of the specified index. The following table lists the recommended conditions for global buffer sharing modes (-i option specified).

Table 26-25 Recommended conditions for global buffer sharing modes (-i option specified)

Determine whether to allocate buffers dedicated to indexes by considering the buffer design guidelines for the -i specification, explained below.

Buffer design guidelines for the -i specification

1. For a non-partitioning index, a partitioning index in the same server, or a partitioning index in the same unit, define a dedicated buffer if each unit within the HA group has sufficient memory capacity to allocate a global buffer.
2. In cases other than 1, define a global buffer for index. Allocate a number of buffer sectors that is appropriate for the sharing servers.

Allocating a global buffer to a non-partitioning index

Specify a non-partitioning index in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

 
pdbuffer -a gbuf01 -i USER01.INDEX01 -n 200 -c
 

Explanation

Non-partitioning index USER01.INDEX01 is specified.

This example allocates a shared global buffer to a non-partitioning index. The global buffer is used exclusively and is not shared with other servers. Even after a system switchover, gbuf01 is used exclusively by BES11, and thus the buffer hit rate does not decline. However, because a buffer to be used after the system switchover must be allocated for each accepting unit, a large amount of memory is used.

Note

The same global buffer is created for all accepting units. This global buffer is not used until a system switchover occurs.

Allocating a global buffer to a partitioning index in the same server

Specify an index that is partitioned in the same server in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

 
pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c
 

Explanation

USER01.INDEX01, an index with row partitioning in a server, is specified.

This example allocates a shared global buffer to an index partitioned in the same server. The global buffer is used exclusively and is not shared with other servers. Even after a system switchover, gbuf01 is used exclusively by BES11, and thus the buffer hit rate does not decline. However, because a buffer to be used after the system switchover must be allocated for each accepting unit, a large amount of memory is used.

Notes

• The same global buffer is created for all accepting units. This global buffer is not used until a system switchover occurs.
• To improve memory efficiency, specify index RDAREAs of the same page size.

Allocating a global buffer to a partitioning index in the same unit

Specify an index that is partitioned in the same unit in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

 
pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c
 

Explanation

This example allocates a shared global buffer to an index partitioned in the same unit. Even after a system switchover, gbuf01 is used, and thus the buffer hit rate does not decline. However, because a global buffer to be used after the system switchover must be allocated for each accepting unit, a large amount of memory is used.

Notes

• The same global buffer is created for all accepting units. This global buffer is not used until a system switchover occurs.
• A global buffer with this specification is shared by multiple servers.
• To improve memory efficiency, specify index RDAREAs of the same page size.
• The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified index RDAREAs.

Allocating a global buffer to an index partitioned between units but not in each unit

Specify an index that is partitioned between units but not in each unit in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

 
pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c
 

Explanation

USER01.INDEX01, an index that is row partitioning between different units, is specified.

This example allocates a global buffer to an index partitioned between units but not in each unit. Before reduced operation, the gbuf01 resource (buffer) is used exclusively by BES11. During reduced operation, because the resource is shared between BES21 and BES11, the amount of the resource (buffer) that can be used by each back-end server is halved.

Notes

• Because the switching destination is a single unit, the workload on the global buffer of that unit alone becomes high. Therefore, define multiple buffers to be shared by servers at multiple units so that the workload among individual units is balanced.
• The same global buffer is created for all accepting units.
• A global buffer with this specification is used exclusively by a single server during normal operation and is shared among multiple servers during reduced operation.
• To improve memory efficiency, specify index RDAREAs of the same page size.
• The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified index RDAREAs.

Allocating a global buffer to an index partitioned between units and in each unit

Specify an index that is partitioned between units and in each unit in the -i option of the pdbuffer operand.

System configuration example

Global buffer definition

 
pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c
 

Explanation

USER01.INDEX01, an index with row partitioning in each unit and between servers, is specified.

This example allocates a shared global buffer to an index partitioned between units and in each unit. During normal operation, back-end servers in the units share each gbuf01, and the amount of the buffer resources allocated to each back-end server is one half of the total. During reduced operation, the three back-end servers share gbuf01, so the amount of the buffer resources allocated to the back-end servers in each unit is one-third of the total.

Notes

• Design the configuration so that the number of servers to be supported during reduced operation is equalized among the individual accepting units.
• The same global buffer is created for all accepting units.
• A global buffer with this specification is shared by multiple servers.
• To improve memory efficiency, specify index RDAREAs of the same page size.
• The buffer size when the -l option of the pdbuffer operand is omitted is the maximum page size of the specified index RDAREAs.

(d) Allocating a global buffer for OTHER (-o option specified)

One global buffer for OTHER can be allocated to all units to which the standby-less system switchover (effects distributed) facility is applied. The following explains the allocation method:

• Within a system, you can define only one buffer for OTHER with the -c option of the pdbuffer operand. If you use the -c option to define multiple buffers for OTHER, the first one defined in the system common definition is valid.
• Out of the RDAREAs allocated to the host BESs and guest BESs that run in the units to which the standby-less system switchover (effects distributed) facility is applied, the buffer for OTHER is allocated to those RDAREAs to which no global buffer has been allocated with the -r option.
• When a buffer size is omitted in the -l option of the pdbuffer operand, if there are RDAREAs to which no global buffer has been allocated with the -c or -r option within the same HA group, the maximum page size of these RDAREAs is used as the buffer size for the buffer for OTHER. If global buffers have been allocated to all RDAREAs in the HA group with the -c or -r option specified, the maximum page size of the specified RDAREAs in the HA group is used.
• You can simultaneously define a global buffer for OTHER with the -c option of the pdbuffer operand specified and another without the -c option specified. The following table indicates the relationship between global buffers for OTHER that are specified in duplicate.
  

  Table 26-26 Relationship between global buffers for OTHER that are specified in duplicate

  Definition of a global buffer for OTHER with -c option specified	Definition of a global buffer for OTHER without -c option specified	Unit to which the standby-less system switchover (effects distributed) facility is applied	Unit to which the standby-less system switchover (effects distributed) facility is not applied
  Yes	Yes	Allocates the buffer defined with the -c option specified.	Allocates the buffer defined without the -c option specified.
  Yes	No	Allocates the buffer defined with the -c option specified.	Allocates the buffer defined with the -c option specified.
  No	Yes	Does not allocate a buffer for OTHER.	Allocates the buffer defined without the -c option specified.
  No	No	Does not allocate a buffer for OTHER.	Does not allocate a buffer for OTHER.

Recommended conditions for a global buffer for OTHER

• System in which RDAREAs are added on an online basis
• RDAREAs with a low access frequency
• RDAREAs with a small number of accessed pages
• RDAREAs storing an extremely large number of pages (RDAREAs for which buffer hits are not expected)

Notes about a global buffer for OTHER

• The resources of a global buffer for OTHER allocated to units are divided and used equitably among these units. Therefore, specify in the -n option of the pdbuffer operand a buffer sectors count that is appropriate to the number of servers used.
• In a system in which RDAREAs are added on an online basis, specify a buffer size in the -l option of the pdbuffer operand by taking into consideration the page sizes of the RDAREAs that will be added in the future.

Allocation example of a global buffer for OTHER

Specify the -o option of the pdbuffer operand.

System configuration example

Global buffer definitions

 
pdbuffer -a gbuf01 -r RDAREA11 -n 500 -c
pdbuffer -a gbuf02 -o -n 1000 -c
 

Explanation

The -o and -c options of the pdbuffer operand are specified.

A dedicated buffer is allocated to RDAREA11 and a global buffer for OTHER is allocated to all other RDAREAs. The global buffer for OTHER is created for all units to which the standby-less system switchover (effects distributed) facility is applicable.

(e) Allocating a global buffer during a configuration change (database reorganization utility)

Specify the name of an existing global buffer in the globalbuffer operand of the control statement of the database reorganization utility. You can use the pdbufls command to check the existing global buffers.

System configuration example

Configuration changed definition

 
create rdarea RDAREA13 globalbuffer gbuf01 server name BES11
                :
 

Explanation

Shared global buffer gbuf01 is allocated for added RDAREAs. The added RDAREAs use gbuf01 even after a system switchover.

Design guidelines

• During both system switchover processing and system reactivation, allocate the global buffer specified with the globalbuffer operand.
• You cannot allocate an index global buffer or a LOB global buffer.
• The size of the global buffer to be specified must be greater than the page size of any RDAREA to be added. You can use the pdbufls command to check the global buffer size.
• The global buffer allocation specified here becomes invalid when the server terminates normally (normal or planned termination of the HiRDB system, normal termination of the unit, or normal termination of the server itself). Therefore, before the server starts normally the next time, you must use the pdbuffer operand in the system common definition to allocate global buffers. However, if a global buffer with the -o option specification has been allocated, that global buffer is allocated again, and therefore there is no need to modify the system common definition.
• When HiRDB fails to allocate a global buffer, no RDAREAs can be added.

Executor: HiRDB administrator or auditor

The HiRDB administrator creates audit trail files on a shared disk of the regular unit. During this process, the HiRDB administrator must select a destination disk that is different from the individual servers' shared disks (disks that store individual servers' system log files, synchronization point dump files, and server status files).

At the system switchover destination, the audit trail files of the accepting unit are shared.

The HiRDB administrator and the auditor can use the audit trail files of both the regular unit and the accepting unit.

(a) Creating audit trail files

The HiRDB administrator creates audit trail files on a shared disk of the regular unit. During this process, the HiRDB administrator must select a destination disk that is different from the individual servers' shared disks (disks that store individual servers' system log files, synchronization point dump files, and server status files).

If audit trail files are created on a shared disk that corresponds to individual servers, the disk's host is switched when a system switchover occurs. Consequently, other running servers in the unit can no longer output audit trails. At the system switchover destination, the audit trail files of the accepting unit are shared.

(b) Using audit trail files

When a system switchover occurs, HiRDB records monitored events in the audit trail file being used by the accepting unit at the switching destination. In this case, operation of audit trail files related to monitored event records is managed centrally by the accepting unit.

For a system that uses the standby-less system switchover (effects distributed) facility, audit trails must be collected at all units.

(c) Collecting audit trails

When a system switchover occurs, whether an audit trail is collected depends on the accepting unit's status. The following table describes collection of audit trails when the standby-less system switchover (effects distributed) facility is used.

Table 26-27 Collection of audit trails when the standby-less system switchover (effects distributed) facility is used

The following figure shows an audit trail collection example when the standby-less system switchover (effects distributed) facility is used.

Figure 26-91 Audit trail collection example when the standby-less system switchover (effects distributed) facility is used

(d) Executing the pdload command

The HiRDB administrator executes the pdload command using the audit trail files of the regular unit and the accepting unit as the input information (certification is done by the auditor). The audit trails of the server that was switched are processed as server information belonging to the accepting unit.

When a factor such as an error caused a system switchover, HiRDB will not have correctly collected the audited events that occurred immediately before the system switchover. For this reason, even if the pdload command is executed, it might not be possible to collect the data that existed immediately before the system switchover.

When a factor such as a system switchover causes the number of running systems in the unit targeted for an effects-distributed standby-less system switchover to fall to 0, the pdload command cannot be executed on the unit to collect audit trail files. In this case, first switch one or more running servers to the unit, and then execute the pdload command.

Operation during an error:

If an error occurs, load the audit trails as follows:

1. At the running host, manually activate the disk storing the audit trail files collected before the system switchover.
2. Using the audit trail files of the regular unit and the accepting unit as the input information, execute the pdload command.

Operation after error recovery:

Load the audit trails using the same method that was used before the error occurred.

When you use the NetBackup linkage facility in a system switchover configuration, the environment assignments and operations described below are necessary if the recovery is carried out on a NetBackup client different from the NetBackup client from which a backup was acquired. Apply these environment assignments and operations only when JP1/VERITAS NetBackup 5.0 or later is being used.

• Create the following empty file on the machine on which the NetBackup master server is installed:
  /usr/openv/NetBackup/db/altnames/No.Restrictions
  
• You need to change the NetBackup client name to be used for recovery (the client name to be set in the policy) to the NetBackup client name from which the backup data to be used for recovery was acquired. For details about how to change the NetBackup client name and other information, see the documentation included with NetBackup.