The basic configuration of a HiRDB/Parallel Server 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 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 HiRDB/Parallel Server.

HiRDB/Parallel Server uses the following memory.

• Shared memory
• Process private memory

(a) Storage requirements

The storage space required by the HiRDB/Parallel Server 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.

(b) Page locking shared memory

With HiRDB, the following types of shared memory can be locked 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

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

Prerequisites

The prerequisites for page locking of shared memory are described below.

Windows version

In Windows, pages are locked using the Large Page facility supported starting with Windows Server 2003 Service Pack 1. For this reason, it is assumed that you have a version of Windows the supports Large Pages. Use the pdntenv -os command to check whether your version of Windows supports page locking.

Page lock privileges

You must have privileges that allow locking of pages in memory in order to lock shared memory pages. Depending on the account you logged on with when executing services, you might not have this privilege. The follow describes how to set privileges.

Logon account used during service execution	How to set privileges
HiRDB administrator	Choose the OS's Local Security Settings, then Local Policies, then User Rights Assignment, and then add the HiRDB administrator under Lock pages in memory.
Local system account	The local system account has authority to lock pages in memory. No privileges need to be set.

Operating environment settings

To lock shared memory pages, you must specify shared memory allocation destinations. Specify page with the pdntenv command's -shmfile option, and then set shared memory allocation destinations in the paging file (virtual memory).

Page locking methods

This subsection describes shared memory page locking 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 locks 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 locked. HiRDB operation when page locking fails is as follows.

  Shared memory for unit controllers or global buffers

  Shared memory is secured without locking pages, and processing continues.

  Shared memory that uses dynamically changed global buffers, or shared memory for in-memory data buffers

  HiRDB or the command terminates abnormally.