DB2 UDB Installation

This chapter is from the book 

Before You Begin

Before you begin installing DB2 on Solaris, you should:

• Review the Quick Beginnings manual sections pertinent to installing DB2 on Solaris.

• Apply patches for your Solaris operating environment:

  • Recommended patches

  • Security patches

  • SUNwlibc patch

• Update the kernel configuration parameters (and reboot).

• Verify that adequate SWAP space is available.

Applying Patches for Solaris Operating Environment

Appropriate patches should be applied to your system before you begin to install DB2. See the installation notes for information about the patches that should be installed to your Solaris operating environment. You can find the installation notes on your installation media (the CD) at:

/CDROM/doc/LN/install.txt

and

/CDROM/doc/LN/release.txt

where /CDROM is the mount point of the CD-ROM and LN represents the language environment (such as en_US, de_DE, etc.).

The manual DB2 UDB for UNIX Quick Beginnings, as well as the online documentation, which is viewable in pdf or HTML format, is downloadable from the IBM Library Web site. It contains the minimum prerequisites for DB2 and is an excellent starting point. You should also at least scan the Readme file and installation notes before you begin installation for the latest information available.

Updating the Kernel Configuration Parameters

Properly set kernel configuration parameters are critical for correct operation of DB2 UDB on Solaris. In fact, creating a DB2 instance checks for certain minimum values in the kernel configuration and will fail if the values are not set appropriately. To maximize the benefits from the power of a Sun server running DB2 UDB on the Solaris operating environment, you must set values for some kernel configuration parameters related to IPC. These parameters are related to the IPC messages, IPC semaphores, and IPC shared memory. The following is a list of these kernel configuration parameters:

For IPC messages

msgsys:msginfo_msgmax is the maximum size of a single message. Must be at least 65,535 (64k).

msgsys:msginfo_msgmnb is the maximum number of bytes that can be put on a single message queue. It must be at least 65,535 (64k).

msgsys:msginfo_msgssz is the size of each message segment in bytes. The product of this value and msgsys:msginfo_msgseg is the total number of bytes available on the system for messages. Increasing this value can increase performance, especially for the load utility (try 64).

msgsys:msginfo_msgseg is the number of message segments configured on the system. Each message is normally broken into multiple segments by the OS. The current maximum value is 32,767.

msgsys:msginfo_msgmap is the number of entries in the message map. It should be set to msgsys:msginfo_msgtql+2.

msgsys:msginfo_msgmni is the maximum number of message queues on the system. Up to five message queues are required for each active database. The DB2 load utility also uses a variable number of message queues (at least one per index on a table being loaded).

msgsys:msginfo_msgtql is the maximum number of individual messages outstanding on the system. The DB2 load utility, in particular, sends a large number of small messages. If a load hangs unexpectedly, try doubling this parameter.

For IPC semaphores

semsys:seminfo_semmap is the number of entries in the semaphore map. It should be set to semsys:seminfo_semmns + 2.

semsys:seminfo_semmni is the number of System V semaphore sets available on the system. Each DB2 engine process and local application requires a semaphore set.

semsys:seminfo_semmns is the number of System V semaphores available on the system. Each semaphore set used by DB2 consists of two semaphores on average. Set this to twice the value of semsys:seminfo_semmni.

semsys:seminfo_semmnu is the number of undo structures available on the system. Each DB2 semaphore potentially requires an undo structure. Set this to the value of semsys:seminfo_semmns.

semsys:seminfo_semume is the number of undo structures per process. It must be at least five.

For IPC shared memory

shmsys:shminfo_shmmax is the maximum size of a single shared memory segment. The recommended value is 90 percent of the size of the physical RAM in bytes. Note that this has no bearing on the actual amount of RAM consumed by DB2; it only limits the maximum buffer pool size you can configure. Buffer pools will be reviewed in Chapter 4, “Creating Database Objects.”

shmsys:shminfo_shmmni is the maximum number of shared segments available on the system. DB2 requires up to three segments per active database, plus one per local application, plus up to three per database instance.

shmsys:shminfo_shmseg is the maximum number of shared segments that a single process may attach to. Currently, a DB2 engine-side process may require up to seven segments.

Because systems and requirements vary, and the resources necessary for proper system utilization can be different based on local policies and applications, a tool is provided to recommend a starting point for kernel settings. Shipped with DB2 is db2osconf, a utility that will analyze your system and suggest a starting point for /etc/system kernel values. The utility can accept various input options to calculate the values based on something other than the full system.

Command Syntax for db2osconf

To get the list of currently supported options, simply enter db2osconf –h, as illustrated in Figure 2.3.

Figure 2.3. db2osconf –h Output

For a complete description of these parameters, review the DB2 manuals.

The following section provides an example of how to use db2osconf.

Example Usage of db2osconf

Here is a sample output produced by running the tool with the -t switch set for 500 threads.

db2osconf -t 500
   
   set msgsys:msginfo_msgmax = 65535
   set msgsys:msginfo_msgmnb = 65535
   set msgsys:msginfo_msgssz = 32
   set msgsys:msginfo_msgseg = 32767
   set msgsys:msginfo_msgmap = 2562
   set msgsys:msginfo_msgmni = 2560
   set msgsys:msginfo_msgtql = 2560
   set semsys:seminfo_semmap = 3074
   set semsys:seminfo_semmni = 3072
   set semsys:seminfo_semmns = 6452
   set semsys:seminfo_semmnu = 3072
   set semsys:seminfo_semume = 600
   set shmsys:shminfo_shmmax = 2134020096
   set shmsys:shminfo_shmmni = 3072
   set shmsys:shminfo_shmseg = 600
   
   Total kernel space for IPC:
   0.35MB (shm) + 1.77MB (sem) + 1.34MB (msg) == 3.46MB
   (total)
   

The recommended values for set semsys:seminfo_semume and set shmsys:shminfo_shmseg were the additional values provided by running db2osconf -t 500.

Setting Kernel Parameters

To set a kernel parameter, add a line at the end of the /etc/system file as follows:

set parameter_name=value
   

For example, to set the value of the msgsys:msginfo_msgmax parameter, add the following line to the end of the /etc/system file:

set msgsys:msginfo_msgmax=65535
   

The simplest way to set kernel parameters is either to cut and paste the output of db2osconf to the end of your /etc/system file or to pipe the output of the tool to a file, then cat that file to the end your /etc/system file. As the tool calculates and displays some memory totals for IPC shared memory, you will need to remove that information or comment it out if you cat the file to the end of your system file. You need to reboot your machine after the values of the kernel configuration parameter are changed. Remember that if there are multiple occurrences of the same parameter in the /etc/system, the last one will override the others, so insure that the DB2 values are at the end of the file.

Considerations for Kernel Configuration Parameters

db2osconf provides suggestions for the kernel configuration parameters that are a good start. However, you may need to increase the value for some of the kernel parameters depending on your environment, especially if you are running multiple applications on your system.

First, determine how many IPC messages, IPC shared memory, and IPC semaphores will be needed, and what the values for semsys:seminfo_semmni, msgsys:msginfo_msgmni, and shmsys:shminfo_shmmni should be.

IPC message queues

Seven message queues used when issuing a db2start command, plus one more if intra-partition parallelism is enabled by setting the DBM configuration parameter INTRA_PARALLEL to yes. The db2start command starts the DB2 instance. The DB2 instance and DBM configuration parameter will be explained later.

Two message queues used per active database.

One message queue used per I/O server process. The number of I/O server processes is determined by the DB configuration parameter NUM_IOSERVERS. The number is three per database by default.

One message queue used per connected application only if intra-partition parallelism is enabled by setting the DBM configuration parameter INTRA_PARALLEL to yes.

Three message queues used for each active DB2 command line processor session. The DB2 command line processor will be explained later.

IPC shared memory

Two shared memory segments used when issuing a db2start command, plus one more if intra-partition parallelism is enabled by setting the DBM configuration parameter INTRA_PARALLEL to yes.

One shared memory segment used per active database.

One shared memory segment used per connected application only if intra-partition parallelism is enabled by setting the DBM configuration parameter INTRA_PARALLEL to yes.

One shared memory segment used per connected local application.

Semaphores

Five semaphores used when issuing a db2start command.

Two semaphores used per active database.

One semaphore used per I/O server and I/O cleaner process. The number of I/O server processes and I/O cleaner processes is determined by the DB configuration parameters NUM_IOSERVERS and NUM_IOCLEANERS. The total number of them is four per database by default.

One semaphore used per connected local application.

One semaphore used per DB2 agent or subagent process. One DB2 agent process is forked per connection by default if the DBM configuration parameter INTRA_PARALLEL is set to no. If INTRA_PARALLEL is set to yes, then estimate the degree of parallelism plus one per connection. You can choose the degree of parallelism or let the system do it for you. For detailed information about the degree of intra-partition parallelism, see the online documentation. When you count the DB2 agent processes, you must also count DB2 agents in the idle pool. This number can be the same as the value of the DBM configuration parameter NUM_POOLAGENTS in maximum use.

The following are the other guidelines used to determine the values of the kernel configuration parameters:

msgsys:msginfo_msgmap = msgsys:msginfo_msgmni + 2:
   semsys:seminfo_semmap = semsys:seminfo_semmni + 2
   semsys:seminfo_semmns = semsys:seminfo_semmni * 2
   semsys:seminfo_semmnu = semsys:seminfo_semmns
   

In all cases, you should consider the output of the db2osconf utility first, and only use other values with careful consideration. Consult your Solaris System Administrator, and make sure to allow for multiple applications running on the same system.

Threaded application support

Multi-threaded applications that open multiple database connections may encounter problems if more than 10 connections are opened from the same process. Two Solaris kernel configuration parameters may need to be updated to work around this situation: shmsys:shminfo_shmseg and semsys:seminfo_semume.

As already explained, shmsys:shminfo_shmseg is the number of shared memory segments that a single process may attach to. Each local database connection requires one shared segment; so, this setting must be at least as high as the total number of connections you wish to establish from a single process. The recommended kernel parameter settings provided by the sample file already suggest a value for this parameter that should be adequate for most circumstances.

semsys:seminfo_semume is the number of semaphore undo structures that a single process may have. Each local database connection requires one of these; so, this setting must also be at least as high as the total number of connections you wish to establish from one process. The default Solaris value for this parameter is 10. Since no internal part of DB2 UDB requires a larger setting, there is no recommended setting for this parameter in the DB2 UDB documentation. If more than 10 local connections are required from a single process, this value should be updated. This would be a setting to review if your Web server or application is on the same machine as the database.

Setting up SWAP Space

You need to allocate adequate paging (SWAP) spaces on your Solaris machine. On Solaris systems, the following command displays the amount of real memory in MB on your system:

prtconf | grep Memory

The following command displays the amount of paging spaces:

swap -s

Figure 2.4 demonstrates the use of these two commands:

Figure 2.4. Determining System Memory and SWAP Space

Each field of the swap –s output means:

allocated— The total amount of SWAP space currently allocated for use as backing store.

reserved— The total amount of SWAP space not currently allocated, but claimed by memory mappings for possible future use.

used— The total amount of SWAP space that is either allocated or reserved.

available— The total SWAP space that is currently available for future reservation and allocation.

For performance reasons, the amount of paging space must be adequate on your machine, and you need to increase it in some cases. Here is a rule of thumb:

Start with the same amount of SWAP space as physical memory.

Monitor your usage closely, and review your requirements with your Solaris System Administrator.

You should have a minimum of 1 GB of SWAP no matter how small your machine is.

If the amount of SWAP space is less than the size of the system memory, add more by using the swap -a command, as shown in the following example:

swap -a /dev/dsk/c0t1d0s1
   

Replace /dev/dsk/c0t1d0s1 with the name of an available disk partition that you wish to use for SWAP space.

Then, add the following entry in /etc/vfstab so that the SWAP space will be activated automatically each time the system is rebooted:

/dev/dsk/c0t1d0s1 - - swap - no –