The basic configuration of a HiRDB parallel server configuration consists of a front-end server, dictionary server, and back-end server on the same server machine.

If the CPU workload of the server machine is low, multiple servers may be placed on one server machine. In such a case, more shared memory is required. If there is not enough shared memory, unit startup fails; for this reason, sufficient memory must be allocated.

The following table shows the ranges for the number of servers that can be installed.

Table 9-1 Number of permitted servers

Item	Number of permitted servers
Number of system managers	1
Number of front-end servers	1 to 1,024
Number of dictionary servers	1
Number of back-end servers	1 to 16,382
Number of servers per unit	1 to 34

The server machine on which the system manager is defined should be at a location that is easily accessible by the HiRDB administrator for the following reasons:

• The HiRDB administrator uses operation commands to operate HiRDB, and most operation commands must be entered from the server machine on which the system manager is defined.
• When HiRDB system definition files are shared, they should be placed on the server machine on which the system manager is defined. For details about how to share HiRDB system definition files, see 4.2.3 Sharing HiRDB system definition files (HiRDB parallel server configuration).

When a complicated retrieval such as join processing is executed, it is better for HiRDB to use a back-end server that does not have a database in order to improve performance. If the server machine has sufficient space and complicated retrieval processing is to be performed, installation of a floating server should be considered. When a floating server is installed, a HiRDB file system area for work table files must be created. The name of this HiRDB file system area is specified in the pdwork operand of the back-end server definition.

If the CPU workload for SQL processing is too high to be processed on the front-end server, multiple front-end servers can be set up. This is called multiple front-end servers; for details, see 9.1.3 Setting up multiple front-end servers.

This subsection describes the memory used by a HiRDB parallel server configuration.

A HiRDB parallel server configuration uses the following memory.

• Shared memory
• Process private memory

(a) Storage requirements

The storage space required by the HiRDB parallel server configuration must be estimated for each server machine. For details about how to estimate the storage requirements, see 15.2 Estimating the memory size required for a HiRDB parallel server configuration.

(b) Page fixing of shared memory

With HiRDB, the following types of shared memory can be fixed in actual memory.

• Shared memory for unit controllers
• Shared memory for global buffers
• Shared memory used by dynamically changed global buffers
• Shared memory for in-memory data buffers

Fixing shared memory in actual memory reduces the number of page I/Os, resulting in more stable performance.

Prerequisites

The following table shows the prerequisites for page fixing of shared memory for each OS.

OS	Prerequisites
HP-UX	None
Solaris	None
AIX	Must be 64-bit mode
Linux	None

Operating environment settings

AIX requires you to set operating system parameters. For details, see 20.3(1) Specifying parameters unique to AIX.

Page fixing methods

This subsection describes shared memory page fixing methods for each type of shared memory.

• Shared memory for unit controllers
  Specify fixed in the pd_shmpool_attribute operand of the system common definition or unit control information definition.
  
• Shared memory for global buffers
  Specify fixed in the pd_dbbuff_attribute operand of the system common definition or unit control information definition.
  
• Shared memory used by dynamically changed global buffers
  Specify fixed in the pd_dbbuff_attribute operand of the system common definition or unit control information definition. This fixes shared memory used by global buffers dynamically changed by the pdbufmod command in actual memory.
  
• Shared memory for in-memory data buffers
  Specify fixed in the pdmemdb command -p option.
  

  Note

  When contiguous areas cannot be secured in actual memory, shared memory pages cannot be fixed. HiRDB operation when page fixing fails is as follows.

  OS	HiRDB operation when page locking fails
  	Unit controller shared memory	Global buffer shared memory	Dynamically changed global buffer shared memory	In-memory data buffer shared memory
  HP-UX	Y	N	N	N
  Solaris	Y	N	N	N
  AIX	Y#	Y#	Y#	Y#
  Linux	Y	N	N	N

  Legend

  Y: Shared memory is secured without fixing pages, and processing continues.

  N: HiRDB or the command terminates abnormally.

  #

  In AIX, system calls terminate normally, even when page fixing fails. This means that you cannot tell from HiRDB that page fixing failed. Use the following procedure to check whether pages were fixed.

  1. While HiRDB is running, execute the pdls -d mem command to check the identifier of the following shared memory segment.

  For shared memory for unit controllers, the shared memory segment with MANAGER displayed under SHM-OWNER.

  For other types of shared memory, the shared memory segment with a character string consisting of the unit name in parentheses or the HiRDB server name displayed under SHM-OWNER.

  2. Execute the OS's ipcs -s command, and then check the SID value of the shared memory that has the identifier of the shared memory segment you checked in step 1.

  3. Execute the OS's svmon command on the SID value you checked in step 2, and then check whether the number of actual memory pages of the shared memory in question matches the number of fixed pages.