3. Installation considerations and planning

After verifying that your system meets the basic requirements, you need to plan your installation by considering installation methods, storage planning, and the creation of users and groups:

3.1. Installation methods

You can use four methods to install DB2 UDB:

Each method has its own advantages and disadvantages. The preferred method often depends on your level of expertise and type of environment, but in general, if a graphical terminal is available, using db2setup is recommended.

3.1.1. db2setup installation

The db2setup command starts the DB2 UDB Setup wizard, a Java-based graphical tool that installs DB2 UDB. It lays down the DB2 UDB filesets, the IBM SDK for Java, and allows you to create DB2 UDB instances, create new users and groups, configure existing users, configure communications, create the tools catalog database, and set up notification. The DB2 UDB Setup wizard also allows you to create a response file.

Using db2setup is the best method for less experienced users, because most of the configuration is automatically performed during the installation. Again, you require X Window System software capable of rendering a graphical user interface, to use db2setup successfully.

3.1.2. db2_install installation

The db2_install command starts the db2_install script. This script installs all DB2 UDB packages on your Linux system using the RPM installation utility. This method is reliable and commonly used by expert users for installing DB2 UDB on larger, more complex multiple-partition systems. However, tasks such as setting up users and groups, creating instances, tools catalog database creation, and notification setup need to be performed manually after the installation is completed.

A limitation to db2_install is that it only installs user assistance (like help, messages, and tool interfaces) in English, whereas db2setup installs support for one or more different languages. Also, a db2_install installation can take longer (considering the higher number of manual configuration tasks), it requires a higher level of knowledge and skill, and it cannot create response files.

3.1.3. Response file installation

A response file can be created using the DB2 UDB Setup wizard or by editing a sample response file. It allows you to install DB2 UDB across multiple machines with consistent installation and configuration settings. A response file installation is fast, because it bypasses the graphical wizard and does the configuration for you. Another advantage of using a response file is that it creates a Database Administration Server (DAS) on each machine, while with db2_install the DAS must be created manually after installation.

The sample response file can be used to install DB2 UDB, configure users, create instances, set up notification, create the tools catalog, and configure a large number of DBM parameters. This is the quickest installation method if you already have all the information you need. Unlike db2setup, the response file installation is not interactive, and it takes longer to prepare the response file.

3.1.4. RPM command installation

The Red Hat Package Manager (RPM) is a Linux software installation command. The various DB2 UDB installation methods use RPM to lay down the appropriate files on the system. Using the RPM command to install DB2 UDB allows you to select specific DB2 UDB files. However, the RPM installation method will only install the DB2 UDB code. It will not create instances, user IDs, or response files during DB2 installation. Please note that this installation method is not officially supported or recommended.

3.2. Storage planning

In this section these storage considerations are discussed:

3.2.1. Raw devices versus file systems

This section describes and compares raw devices and file systems as storage mechanisms for DB2 UDB on Linux, and how to configure them.

3.2.1.1. Raw device configuration

Raw devices can only be used for Database Managed Storage (DMS). DMS table spaces require more administration, but provide superior performance over System Managed Storage. Using raw I/O improves performance because it bypasses the buffering performed by the Linux kernel and allows processes to interact with the physical device directly. In comparison, the file system uses system-based I/O, which means that data is buffered twice: first at the database manager level and then at the kernel (or file system) level. At this level, the kernel intercepts the calls and transfers the data to its own buffer before passing it on to the physical device or process. The additional buffering impedes performance.

To perform raw I/O on a block device, you must first bind the Linux kernel's pool of raw device nodes to that block device. This is done by running the raw command as root. The raw utility is normally supplied by the Linux distribution.

For example, if your disk partition is /dev/hda12 and you want to bind it to /dev/raw/raw1, enter the command:
bash# raw /dev/raw/raw1 /dev/hda12
Next, configure the /etc/rc.d/boot.local file so that DB2 UDB can access the raw device at boot time. This configuration is done by adding entries to /etc/rc.d/boot.local:
raw /dev/raw/raw1 /dev/hda12 raw /dev/raw/raw2 /dev/hda13
To show all current raw devices available, issue the following command:
raw -qa
You should receive output similar to:
/dev/raw/raw1: bound to major 3, minor 12
/dev/raw/raw2: bound to major 3, minor 13
For detailed instructions on how to set up raw I/O on your Linux computer, refer to the IBM DB2 UDB Administration Guide: Implementation documentation.

3.2.1.2. File system configuration

A popular method for configuring disk space for DB2 UDB on Linux is to use separate file systems to store and run DB2 UDB. File systems can be used by DB2 UDB either as system managed storage (SMS) or as database managed storage (DMS). SMS table spaces are commonly used because they provide good performance with very little administration cost. File systems have many benefits. For example, they can be distributed across a network and have network-oriented authentication and replication capabilities, which makes them essential for a multiple-partition database system.

You should create different partitions during your Linux OS installation. It has become customary for certain basic directories, such as /db2home to be placed in separate file systems, or partitions, for several reasons:

  • Disk capacity - there is a limited amount of space on each disk, and you might run out of space if you use a single disk for multiple purposes.

  • Performance - the root directory has to be searched linearly every time any path name in Linux is accessed. If the root directory is cluttered, this will impair performance of the entire system.

  • Backup - it is better to separate frequently changing data from seldom changing data. This way you can save system resources by backing up some file systems more frequently than others.

  • User convenience - it is easier to find things if the naming convention is well-organized.

File system configuration, or partitioning, is typically performed by using the fdisk tool. Red Hat Linux has a graphical disk configuration utility; for SuSE Linux, you can also use the graphical YaST tool. Linux provides several journal file system formats, such as Ext3, JFS, XFS and ReiserFS.

For example, to show all defined file systems, issue the df command. You should receive output that is similar to this:

Filesystem   1K-blocks   Used      Available   Use%   Mounted on
/dev/hda1    4200828     1588840   2611988     38%    /
/dev/hda5    54416       4682      46925       10%    /boot
/dev/hda8    3099260     32828     2909000     2%     /database
/dev/hda9    1035660     32828     950224      4%     /db2log1
/dev/hda10   2071384     32828     1933332     2%     /db2temp
/dev/hda7    1035660     32828     950224      4%     /db2home_Local
/dev/hda11   3099260     20        2941808     1%     /software_Local
/dev/hda19   1035660     32828     950224      4%     /db2log2
To show all NFS mounted file systems, issue the showmount -a command on the host where the file system physically exists. You should receive output that is similar to this:
udblnx03.local:/software
udblnx04.local:/software
udblnx05.local:/software

There are many different ways to configure disk partitions and file systems, depending on your environment. You should follow these recommendations when configuring your system:

  • For single-partition and multiple-partition database systems, you should create a separate file system for the DB2 UDB user home directories. Avoid creating databases on this file system. For multiple-partition environments, you should create a separate DB2 UDB home file system on one of the machines in the cluster to be used as the instance home directory. This file system is to be shared between all machines in the cluster via NFS (that is, NFS-exported from the NFS server machine, and NFS-mounted on the remaining machines).

  • You should create a separate file system for database storage. For multiple-partition database systems, there should be a separate database file system on each physical system that participates in the partitioned database.

  • For performance or availability reasons, you should avoid putting user data on the catalog node. When restoring the catalog node, the restore is faster when there is no data on this node.

  • You should create separate partitions for the primary copy of DB2 UDB logs, DB2 UDB mirrored logs, and DB2 UDB temporary table spaces. In addition, you may want to create a separate file system for user table spaces in order to separate them from the database files. This configuration is commonly used in many production environments.

Here is an example of one possible configuration:

Table 6. Partition configuration

Partition name

Description

/

Linux

/boot

Linux

/swap

Linux Swap space

/db2home

For storing the home directories for DB2 UDB users (for example, db2inst1, db2fenc1, dasusr1)

/database

For storing the database

/db2log1

Used to storing primary copy of logs

/db2log2

Used to store DB2 UDB mirrored logs

/db2temp

For storing DB2 UDB temporary table spaces

/software

Used for storing software. For example, we downloaded the DB2 UDB install image into this directory.

/tablespaces

Holds all user table spaces

Note

Mirroring log files helps protect a database from accidental deletion of an active log and data corruption caused by disk error. While this functionality increases the high availability of a system, log mirroring may impact system performance as all log data will be written to both the log path and the mirror log path.

3.2.2. Log storage

By default, DB2 UDB sets the log path to the default database path during database creation.

You should store both the primary copy of the logs and the mirror logs each on a physically separate disk, preferably one that is also on a different disk controller.

Mirror logs are created using the MIRRORLOGPATH configuration parameter. Log mirroring allows the database to write an identical second copy of log files to a different path. For example, you can change the primary log path from the default to /db2log1, and set the mirror log path to /db2log2 by issuing these commands:
db2 update db cfg for db_name using NEWLOGPATH /db2log1
db2 update db cfg for db_name using MIRRORLOGPATH /db2log2

Note

These changes will only take place after you deactivate and activate your database, using the db2stop and db2start commands.

3.2.3. Temporary table space storage

DB2 UDB uses system temporary table spaces for many SQL operations, such as JOIN and SORT. The temporary table space, TEMPSPACE1, is one of the three default table spaces (SYSCATSPACE, TEMPSPACE1, and USERSPACE1) that gets created during database creation. By default, TEMPSPACE1 gets placed in the database path. For larger systems, we recommend that your temporary tables paces are located on a separate file system and disk.

In a multiple-partition database environment, the catalog node should contain all three default table spaces, and the other database partitions should each contain only TEMPSPACE1 and USERSPACE1.

The following example shows how to create a system temporary table space on multiple nodes in the /db2temp file system:
connect to db_name;
create temporary tablespace TEMPSPACE01 in IBMTEMPGROUP
managed by SYSTEM
using ('/db2temp/$INSTANCE/db_name/n001tmp/tempspace01') on \
    dbpartitionnum (1)
using ('/db2temp/$INSTANCE/db_name/n002tmp/tempspace01') on \
    dbpartitionnum (2)
using ('/db2temp/$INSTANCE/db_name/n003tmp/tempspace01') on \
    dbpartitionnum (3)
using ('/db2temp/$INSTANCE/db_name/n004tmp/tempspace01') on \
    dbpartitionnum (4)
extentsize 32
prefetchsize 128
bufferpool IBMDEFAULTBP
overhead 24.1
transferrate 0.9;
drop tablespace
tempspace1;

3.3. User and group setup

DB2 UDB requires user IDs and groups. This section discusses these IDs and groups and how to create them.

3.3.1. User and group requirements

DB2 UDB requires a minimum of three users and groups: the instance owning user, the fenced user, and the Database Administration Server (DAS) user. You may use the default names provided by the setup utilities, or specify your own user and group names. For example, consider the following default user IDs and group names produced by the DB2 UDB Setup wizard:

Table 7. Default user IDs and group names

Required user

User name

Group name

Description

Instance owner

db2inst1

db2iadm1

Administers the instance

Fenced user

db2fenc1

db2fadm1

Responsible for executing fenced user defined functions, such as JDFs and stored procedures.

DAS user

dasusr1

db2asgrp

Administers the DB2 UDB Administration Server

3.3.2. Creating users - single-partition

You must have root authority to create users and groups. There are three ways in which you can create a DB2 UDB user ID:

  • DB2 UDB Setup Wizard. The DB2 UDB Setup Wizard creates all of the required users and groups for you during installation. The default users and groups that get created are displayed in the previous table. DB2 UDB Setup also gives you an option to specify your own user and group names.

  • Response file. Users can also be created during a response file installation if you specify user and group information in the response file. For example, consider the following entries in a response file that create the three required users and groups for DB2 UDB:
    * DAS user
    DAS_USERNAME = dasusr1
    DAS_GROUP_NAME = dasadm1
    DAS_HOME_DIRECTORY = /home/dasusr1
    DAS_PASSWORD = 235262333285355231346
    ENCRYPTED = DAS_PASSWORD
    * Instance-owning user
    inst1.NAME = db2inst1
    inst1.GROUP_NAME = db2grp1
    inst1.HOME_DIRECTORY = /db2home/db2inst1
    inst1.PASSWORD = 235262333285355231346
    ENCRYPTED = inst1.PASSWORD
    inst1.AUTOSTART = YES
    inst1.AUTHENTICATION = SERVER
    inst1.SVCENAME = db2c_db2inst1
    inst1.PORT_NUMBER = 50001
    inst1.FCM_PORT_NUMBER = 60000
    inst1.MAX_LOGICAL_NODES = 4
    * Fenced user
    nst1.FENCED_USERNAME = db2fenc1
    inst1.FENCED_GROUP_NAME = db2fgrp1
    inst1.FENCED_HOME_DIRECTORY = /db2home/db2fenc1
    inst1.FENCED_PASSWORD = 235262333285355231346
    ENCRYPTED = inst1.FENCED_PASSWORD

  • Manually using command line. To use this method, follow these steps:

    1. Log on to your machine as root.

    2. Create groups for the instance owner, the fenced user and the DAS user by using these commands:
      groupadd db2iadm1
      groupadd db2fadm1
      groupadd db2asgrp
      Linux will create the groups using the first available group ID (GID) numbers available over 500. You can specify GID numbers if you prefer.

    3. Create a user that belongs to each group and specify the home directory. For example, you can choose to place all home directories in /db2home by entering these commands:
      
useradd -g db2iadm1 -m -d /db2home/db2inst1 db2inst1 -p password1
      useradd -g db2fadm1 -m -d /db2home/db2fenc1 db2fenc1 -p password2
      useradd -g db2asgrp -m -d /db2home/dasusr1 dasusr1 -p password3

3.3.3. Creating users - multiple-partition

In a multiple-partition database environment, you only need to create one shared home directory for the instance owner and fenced user (but remember to create users on each computer). When creating users in a multiple-partition environment, make sure that the user and group IDs are the same on each machine. Consider the following setup:

  • A shared home directory, /db2home, on the instance-owning machine, which is NFS-mounted on the remaining machines in the cluster. In this directory are found the home directories for the instance-owning user and fenced user: db2inst1 and db2fenc1.

  • A local home directory for the DAS user on each computer, dasusr1, which is stored in the /home directory.

The DB2 Administration Server (DAS) has changed significantly in DB2 UDB Version 8. Therefore, you should take note of the following DAS user considerations.

3.3.3.1. DAS user considerations for a multiple-partition environment

  • A DAS must be running on each physical machine in the multiple-partition database for the graphical administration tools (for example, Control Center) to work.

  • You can only have one Version 8 DAS on each machine (although a V7 and V8 DAS can co-exist on one machine).

  • Just like an instance, each DAS must be created under a user ID. It does not matter whether a different user ID is used for each DAS in the environment, or whether the same user ID is used and that the user ID's home directory is not shared.

  • If the same user ID is to be used on each machine, then that user ID's home directory cannot be shared with the other machines.

  • If a different user ID is used for each DAS, then the home directories of the user IDs that are used can be shared.

  • If an existing user is used as the DAS user, this user must also exist on all the participating computers before installation.

  • For response file installations: If your response file specifies to create a new DAS user on each machine in the cluster, and that user already exists on any of the participating computers, then that user must have the same primary group as the new DAS user.