Bookmark and Share


DB2� Universal DatabaseTM is finding wide use on the Linux platform as a scalable, flexible database solution. If you're a Linux user, you know that the Linux world is diverse, with multiple packages and distributions to choose from -- Red Hat, SUSE, United Linux, and many others, and multiple hardware platforms as well. With such a multiplicity of hardware platforms and Linux distributions, not everything is officially supported and tested on DB2 UDB.

Many distributions of Linux use Red Hat Package Manager (RPM), a command line-driven package management system used for installing, uninstalling, and managing software. The DB2 UDB installation program for Linux is based on RPM. You can find a lot of information on how to install in this environment, such as the IBM Redbook {Up and Running with DB2 Linux}. But if you're considering or have chosen a Linux distribution that's not on the {official list} and one that is not based on RPM, read on. This article is for you.

In this article I will demonstrate how to install and set up DB2 Universal Database on a non-RPM based Linux distribution. We will not cover installation of DB2 data partitioning facilities. This is not an exhaustive guide but is rather a quick start based upon direct customer experience. We will start by looking at some of the basic concepts and terminology in order to make the installation an informative experience.

I became aware of the need for this information when working at with an IBM customer who chose DB2 as an alternative to MySQL for its ability to meet their database scalability requirements. I will cover some of the technical challenges we faced installing DB2 in their environment as well as discuss the solutions we found to these hurdles.

The installation will be based upon the Gentoo,, Linux distribution and DB2 Universal Database V8.1. We choose to use a 2.4.23 version of the kernel and a 2.3.2 level of glibc.



Proceed with care! DB2 V8.1 official support is limited to validated hardware platforms and Linux distributions. To check for the latest validated systems refer to the following Web site: {}.

More information about attaining validation for a Linux distribution can be found here: {}.

Open source developers may wish to develop DB2 applications on non-validated systems for many reasons: personal choice development environment, cutting-edge testing, or other considerations. Running production systems on unsupported systems is not recommended. This article recognizes the ability of the open-source community to pursue alternative solutions.

For more detailed instructions on install and setup of DB2 on validated platforms refer to the Redbook {Up and Running with DB2 for Linux}.

While official support for non-validated systems is not available from IBM support, there are alternative support venues. dBforums at {} runs a useful support Web site. It is a free community-based Web site where questions can be posted as well as useful contacts can be developed. The {DB2 newsgroups} are another source of support. For DB2 documentation, go to {}.


Reviewing basic concepts


The concept of a DB2 instance is important to understand as you go about installing and setting up DB2. An instance is an environment for allocating and managing one or more databases. More than one instance can exist on a single system, but those instances are largely independent of each other. {Figure 1} demonstrates this relationship:
Figure 1. Multiple instances on a single system
[Multiple instances on a single system]
On Server_A there are two instances, db2inst1 and db2inst2. Each instance is hosting two databases. Databases HR and Finance are managed by db2inst1, while Catalog and Customer are managed by db2inst2. Each database hosts corresponding tables.

When a user or application wants to query information from a set of tables it must connect to the corresponding database. To establish this connection the application talks to the TCP/IP port of the instance hosting the requested database, if connecting remotely. Shared memory is used if the connection is local. Once a connection is established, the user may query any table in that database. To query other tables the user must establish new connections to the correct database.

Server resources

Server resources are allocated at both the instance and database level. Allocated instance resources affect all hosted databases, and database resources are only available to the defining database. In addition, security for database administration is organized at the instance level, in effect allowing different database administrators or administration teams to have total ownership of their databases.

Let us take a closer look at the qualities of an instance. An instance on Linux corresponds to a user account. In our above example there would be db2inst1 and db2inst2 users.

When an instance is running, there are a number of processes that run under the instance ID. Some examples are shown in {Figure 2}:
Figure 2. Processes running under the instance Id
[Processes running under the instance Id]
For more information on the DB2 process model refer to {} and the developerWorks db2 article {Everything you wanted to know about DB2 UDB processes}.

It is the instance user that will have ownership of all underlying files for the databases under the management of that instance. The default database path is the instance home directory. To create a database or allocate additional space in a different location on the file system, you will need to give read/write permissions to the instance user.

For example, the following commands will create a database TESTDB on a location outside the instance home directory.
mkdir /usr/data chown db2inst1:db2grp1 /usr/data su � db2inst1 db2 create database TESTDB on /usr/data
Understanding the DAS

The DB2 administration server (DAS) is a special DB2 process. Its primary function is to perform tasks on behalf of client requests from the Control Center and the other GUI tools. In addition, it responds to catalog requests from remote systems providing necessary information about instances and databases available for user connections. There is only one DAS per server. For more information on DAS refer to the {DB2 Information Center}.


Installing DB2

You may think of the installation of a DB2 system as a two step process: installation of the DB2 libraries and the creation of an instance. While there are other administrative steps to make the system easier to manage, these two steps are required to get a system ready to host your first database. We will look at two methods of accomplishing these steps, graphical and non-graphical. Unless otherwise noted, you must perform all steps as the root user.

Using the graphical method

On a system meeting all the requirements, the simple execution of the db2setup script will walk you through both the installation of the binaries and creation of your first instance. On our Gentoo system we were able to perform both installation methods after performing some interruptive operations. I will list the steps below along with an explanation of why each step was necessary if it deviated from a norm. The steps below were created for the initial release version of DB2 V8.1. Logon on with the root ID to ensure ownership of the display.
1. Install RPM � Since DB2 on Linux is RPM -- based, it is necessary to have this tool to unpack and install the libraries. One caveat of installing RPM on a non-RPM-based system is that the RPM database is empty. This will affect other steps of the installation.
2. Install XWindows � Gentoo by default did not install the XWindows libraries. To do the GUI install we naturally needed these.
3. Edit the db2_install script to force dependency checking off. Since the RPM database is empty, checking for dependencies would fail, so we must force the installation to skip this step. There are two db2_install scripts but only one performs the RPM install. The first db2_install script, the one in the root directory of the DB2 install CD or extracted tarball, calls the second to perform the RPM install. It is the second db2_install script that will need to be edited. It should be located in db2_source_root_path/db2/linux/. Add the �--nodeps� option to the RPM installation line �rpm -ivh�. The line should read � rpm --nodeps -ivh � with no changes following.
4. Run the db2_install script from the root directory of the DB2 install CD or extracted tarball. This should work successfully.
5. Create a symbolic link to RPM. While the db2_install scripts only requires RPM to be in the path, the db2setup script (executed in the next step) starts the DB2 installation Java GUI which uses a hard coded path to rpm of /bin/rpm. For Gentoo, RPM was installed into /usr/bin/rpm so the GUI will fail to find RPM. Although DB2 libraries are already installed, as completed in step 4, the GUI attempts to verify the installation before continuing. The command
ln �s /bin/rpm /usr/bin/rpm
will create the link and allow the DB2 GUI to continue to load. If your distribution places RPM in /bin/ then this step is not necessary.
6. Run db2setup and the installation should continue graphically as normal. An alternative to running the db2setup script is to run db2isetup from the installed directory, /opt/IBM/db2/V8.1/instance/.
Using the non-graphical method
1. Install RPM. Since DB2 is RPM-based, it is necessary to have this tool to unpack and install the libraries. One caveat of installing RPM on a non-RPM based system is that the RPM database is empty; this will affect other steps of the installation.
2. Edit the db2_install script to force dependency checking off. Since the RPMrpm database is empty, checking for dependencies would fail, we must force the installation to skip this step. There are two db2_install scripts but only one performs the rpm install. The first db2_install script, the one in the root directory of the DB2 install CD or extracted tarball, calls the second to perform the rpm install. It is the second db2_install script that will need to be edited. It should be located in db2_source_root_path/db2/linux/. Add the �--nodeps� option to the rpm installation line �rpm -ivh�. The line should read � rpm --nodeps -ivh � with no changes following.
3. Create the users for the instance ID (db2inst1), fenced ID (db2fenc1), and DAS ID (dasusr1). When creating these IDs be sure to create their home directories. These IDs can not have the users group as their default group. If not done so during user creation create groups for each of the IDs and make the created groups their primary group. The following step will try to modify the IDs profile scripts, such as .bashrc, to set DB2 environment variables. If the files do not exist you will get an error but the instance will be created successfully. Be sure the skeleton files are created in the users directories or create or copy them manually.
4. Create the instance. Use the following commands to create the DB2 instance and administration server.
./opt/IBM/db2/V8.1/instance/db2icrt �u db2fenc1 db2inst1 ./opt/IBM/db2/V8.1/instance/dascrt �u dasusr1


Setting up client communication

To connect to a DB2 database you must have a DB2 client. (For an exception to this statement refer to {DB2 JDBC type 4 driver support)}.

Whenever you install a DB2 software product you will get the DB2 client functionality. DB2 clients for many platforms can be downloaded from: {}.

Local connections

Local client communication is made via shared memory. To make this work properly certain environment variables need to be set. To set these variables a DB2 script, db2profile, exists in the sqllib directory of the instance user�s home directory.

For example /home/db2inst1/sqllib/db2profile would be the environment setting script for the db2inst1 instance. This script gets run automatically when you login to the db2inst1 account. However, if you wish to access local DB2 databases via other accounts, you simply need to execute this script before attempting to connect to any database in that instance. There is no need to catalog these databases as they are automatically cataloged upon creation.

Remote connections

If you wish to connect to a DB2 database on a remote server you must catalog both the remote system and the database. To do this, two directory entries need to be made, one in the node directory for the system and one in the database directory for the database.
* The node directory lists the location of the server (IP address or hostname of the server) and the port the instance listens to for database connection attempts.
* The database directory lists the database name, the database alias, and the corresponding entry in the node directory to use to establish the connection.
You can make these directory entries with a GUI interface using the Client Configuration Assistant (CCA) or directly through the command line. As you can see in {Figure 3}, the Client Configuration Assistant can send a broadcast looking for running DB2 UDB systems. The DAS on the database server can respond to these broadcasts with the necessary information, and the CCA sets up the appropriate entries.
Figure 3. The Client Configuration Assistant
[The Client Configuration Assistant]
If you prefer, commands can be used to catalog the node and the database directly, as you can see in the following example commands:
db2 CATALOG TCPIP NODE tcpnode REMOTE hostname SERVER port_name SYSTEM system_name OSTYPE os db2 CATALOG DATABASE dbname AS dbalias AT NODE tcpnode
* tcpnode � any value you choose to designate the entry
* hostname � the hostname or IP address of the remote system
* port_name � instance�s listening port as designated in the services file
* system_name � typically the same as the hostname
* os � Operating system type (Linux, Windows, and so on)
* dbname � database name on the server
* dbalias � database alias if database name already exists in the local catalog
* tcpnode � the entry as created in the first command


Additional notes

We found that the DB2 GUI ran much cleaner with the IBM JDK. The IBM 1.3 JDK comes with DB2 V8.1 but is not installed by default using the steps above. To install the IBM JDK, locate the IBM JDK rpm in db2_source_root_path/db2/linux/Java-1.3.

On some platforms however the IBM 1.3 JDK simply will not run. If you wish to use any of the GUI setup tools, be sure you have a working JDK with the Java environment variables set, JAVA_HOME and CLASSPATH.

Once DB2 is installed, the administration GUIs use the database manager configuration parameter JDK_PATH to determine where to execute the Java interpreter. If you are not using the IBM JDK, then you will need to update this parameter in order to run the administration utilities such as the DB2 Control Center. You can update the database manager configuration using the following commands:
su � db2inst1 db2 UPDATE DBM CONFIGURATION USING JDK_PATH /opt/sun_java_jdk_path



In summary, you can use DB2 UDB even if you choose a non-RPM Linux distribution. With a little tweaking of the install process as I've described, you'll be on your way to using the powerful, flexible combination of DB2 UDB and Linux.



I would like to recognize Rodric Glaser and Paul Strange of for providing a great deal of input and technical skill during the writing of this document. It was their desire to build a DB2 system on a non-RPM distribution of choice that demonstrated the need for this document.
About the author

Monty Wright is a certified IT specialist and has been supporting the DB2 brand for 7 years. He has published several articles on DB2 distributed topics and authored the DB2 performance tuning section of the IBM Redbook {Tuning IBM eServer xSeries Servers for Performance}. As part of the IBM Advanced Technical Support ATS team he has participated in numerous customer engagments and benchmarks. His areas of specialty include performance tuning, database partitioning, and high availability.