Additional instructions on setting up DB2 UDB

This file supplements instructions on installing and configuring DB2 UDB 7.2w available in the Version 4.0 InfoCenter under "Installation documentation" at http://www.ibm.com/software/webservers/appserv/infocenter.html. InfoCenter articles on installing DB2 UDB 7.2 document how to install DB2 UDB Version 7.2w, which is provided as part of the WebSphere Application Server Advanced Edition Version 4.0 CD package.

Topics covered in this file include--

Ensuring that you have the level of DB2 UDB needed by WebSphere Application Server (7.2w or later)

DB2 UDB Version 7.2w is the same as the generally available DB2 UDB Version 7.2 with DB2 UDB FixPak 3 and with a DB2 UDB FixPak for WebSphere Application Server.

If you installed DB2 UDB 7.1 or a version of DB2 UDB 7.2 that you did not obtain from the CD-ROM supplied with WebSphere Application Server Advanced Edition 4.0.x, upgrade your installation with a special FixPak to make it compatible with WebSphere Application Server Advanced Edition 4.0.x. Obtain FixPak 3W from the Web site ftp://ftp.software.ibm.com/ps/products/db2/fixes/english-us/WAS4_FP3/. Follow the installation instructions in the FixPak README to apply it to your DB2 UDB installation. Then, apply a DB2 FixPak that supports the cursor hold value.

If you installed the version of DB2 UDB 7.2 provided with WebSphere Application Server Advanced Edition 4.0.x, your installation only requires a DB2 FixPak that supports the cursor hold value.

Note that WebSphere Application Server Version 4.0.2 also supports the use of DB2 UDB FixPak 4 or FixPak 5 with Version 7.2w. For details, see the lists of prerequisite products needed for IBM WebSphere Application Server at http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.

Installing a DB2 FixPak that supports the cursor hold value

In addition to having DB2 UDB 7.2w or its equivalent installed, your DB2 installation must also have the DB2 FixPak that allows a DB2 Version 7 DataSource to support the required cursor hold value. To obtain the FixPak, go to the Supported Software Table at www-4.ibm.com/software/webservers/appserv/doc/latest/idx_eas.htm

If you do not apply the FixPak and you have a connection which returns a resultSet, if you commit the connection without closing the resultSet and try an operation on the connection which requires the connection to be "clean", that operation fails.

Enabling JDBC 2.0

JDBC 2.0 is required for DB2 UDB. When installing WebSphere Application Server Advanced Edition using a Typical Installation (installs the Application Server, IBM HTTP Server and DB2 UDB), you will receive a message to use JDBC 2.0 and to refer to the documentation. If your system is not set up for JDBC 2.0, the administrative server will not start and you will receive a data source error. To use JDBC 2.0, refer to the InfoCenter article "6.6.14.5: Additional administrative tasks for specific databases." The article states as follows as to using JDBC 2.0:

Enabling JDBC 2.0 with DB2 on Windows

To enable JDBC 2.0 use on Windows systems:

  1. Stop the DB2 JDBC Applet Server service.
  2. Run the batch file SQLLIB\java12\usejdbc2.bat.
  3. Stop WebSphere Application Server (if it is running) and start it again.

Perform the steps once for each system.

To see what JDBC level is in use on your system:

Enabling JDBC 2.0 with DB2 on UNIX

Before starting WebSphere Application Server, you need to call $INSTHOME/sqllib/java12/usejdbc2 to use JDBC 2.0. For convenience, you might want to put this in your root user's startup script. For example on AIX, add the following to the root user's .profile:

if [ -f /usr/lpp/db2_07_01/java12/usejdbc2 ] ; then
. /usr/lpp/db2_07_01/java12/usejdbc2
fi

To determine if you are using JDBC 2.0, you can echo $CLASSPATH. If it contains $INSTHOME/sqllib/java12/db2java.zip, then JDBC 2.0 is in use. If it contains $INSTHOME/sqllib/java/db2java.zip, then JDBC 1.0 is in use.

Configuring DB2 UDB on Linux

This section supplements information on configuring DB2 UDB on Linux platforms already in the InfoCenter. The topics covered in this section include--

Configuring the Linux ipcs parameters for the enterprise application environment

To configure the Linux ipcs parameters:

  1. Determine the current setting for the maximum number of message queues by entering the command # ipcs -l.

    The output should resemble the following:

    ------ Shared Memory Limits --------
    max number of segments = 4096
    max seg size (kbytes) = 32768
    max total shared memory (kbytes) = 8388608
    min seg size (bytes) = 1
    
    ------ Semaphore Limits --------
    max number of arrays = 128
    max semaphores per array = 250
    max semaphores system wide = 32000
    max ops per semop call = 128
    semaphore max value = 32767
    
    ------ Messages: Limits --------
    max queues system wide = 128
    max size of message (bytes) = 8192
    default max size of queue (bytes) = 16384
  2. If the value of the max queues system wide parameter is less than 128, increase it by entering the following command:
    # echo 128 > /proc/sys/kernel/msgmni
  3. The value of the max semaphores per array parameter should be at least the same number of semaphores as db2 maxagents (default 200) times the number of processors on the system. If necessary, increase the value to 250. The value of the max ops per semop call parameter should also be increased to 128. These can be set by entering the following command:
    # echo 250 32000 128 128 > /proc/sys/kernel/sem

These parameters will resume to the original value after rebooting your system. You can set these in the user profile.

Increasing the database logfile size to prevent TRANSACTION_ROLLEDBACK errors caused by DB2 deadlock or timeout

  1. Configure the log file size of application databases to prevent the TRANSACTION_ROLLEDBACK error. Set the file size by entering the following command:
    $ db2 UPDATE DATABASE CONFIGURATION for <database-alias> USING LOGFILSIZ 4095
  2. Stop and start DB2 for your changes to take effect using the following commands:
    $ db2stop
    $ db2start

Using the KSH shell for RedHat 7.1

For RedHat7.1, use the KSH shell:

  1. Use the KSH shell to configure the WebSphere Application Server runtime environment and access DB2:
    1. Ensure that you have ksh installed (the pdksh package).
    2. Open an editor on the DB2 usejdbc2 script, which is broken on Linux. For all lines that have
      ]] then

      change the lines to:

      ]] ; then

      (Add a semi-colon.)

    3. Run the usejdbc2 script by entering the command below. Ensure that you have the . in the command so that the environment is updated.
      . usejdbc2
  2. Ensure that you have the correct setting for PATH, CLASSPATH and LD_LIBRARY_PATH. To check if the environment is set up correctly, enter the following command:
    # env | grep PATH

    The correct setting should resemble--

    [db2inst1@lifeng-was4 bin]$ env | grep PATH
    LD_LIBRARY_PATH=/home/db2inst1/sqllib/java12:/home/db2inst1/sqllib/lib
    CLASSPATH=/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java12/db2java.zip
         :/home/db2inst1/sqllib/java/runtime.zip:.
    LIBPATH=/home/db2inst1/sqllib/java12:/home/db2inst1/sqllib/lib
    PATH=/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/X11R6/bin
         :/home/db2inst1/sqllib/bin
         :/home/db2inst1/sqllib/adm
         :/home/db2inst1/sqllib/misc
         :/home/db2inst1/bin
         :/opt/WebSphere/AppServer/bin
         :/opt/WebSphere/AppServer/java/bin
         :/home/db2inst1/sqllib/java12
         :/home/db2inst1/sqllib/lib

    Note that the CLASSPATH and PATH settings are shown here on multiple lines, instead of each on one line, to improve readability.

Configuring the database manager to use TCP/IP to connect to WebSphere remotely

After completing the steps in the section "Creating a database for WebSphere Application Server" in the InfoCenter article "Configuring and testing DB2 UDB 7.2," you must configure the database manager to use TCP/IP to connect to WebSphere remotely on Linux. Because you are using a local DB2 database with WebSphere Application Server (both DB2 and WebSphere Application Server are installed on the same machine), perform the steps below on the same machine.

To configure the database manager to use TCP/IP to connect to WebSphere remotely:

  1. Ensure that you are logged in as the DB2 instance owner db2inst1.
  2. Set DB2COMM to TCP/IP by using the db2set command, as follows:
    $ db2set DB2COMM=tcpip
  3. Use a text editor to open the /etc/services file. If it does not specify DB2 connection port, add the following text to specify the port:
    db2cdb2inst1    50000/tcp  # DB2 connection service port

    Note that you must authenticate as a user with superuser (root) privileges to edit the /etc/services file.

  4. Ensure that you are logged in as the DB2 instance owner db2inst1.
  5. Update the database manager configuration using the db2 update command:
    $ db2 update dbm cfg using svcename DB2_connection_service_port

    In this command, DB2_connection_service_port represents the name of the DB2 connection service port you specified in the /etc/services file (for example, db2cdb2inst1).

  6. Catalog the TCP/IP node using the db2 catalog command:
    $ db2 catalog tcpip node WASNODE remote 127.0.0.1 \
    server DB2_connection_service_port

    In this command, DB2_connection_service_port represents the DB2 connection service port server name specified in the /etc/services file (for example, db2cdb2inst1).

  7. Catalog the database by entering the following commands:
    $ db2 catalog db WAS40 as WASLOOP
    $ db2 uncatalog db WAS40 
    $ db2 catalog db WASLOOP as WAS40 at node WASNODE
  8. Stop and start DB2 for your changes to take effect using commands:
    $ db2stop
    $ db2start

Verifying a connection to a DB2 UDB database

The steps below supercede those in the section "Verifying the connection to the database" in the InfoCenter article "Configuring and testing DB2 UDB 7.2." Note that, although the steps instruct you to verify a connection to the database named wasloop, the default name of the WebSphere Application Server repository is was40.

Do the following to verify a connection to a database named wasloop:

  1. Ensure that you are logged in as the DB2 instance owner db2inst1.
  2. Connect to the database named wasloop using the db2 connect command:
    $ db2 connect to wasloop

    Correct output resembles the following:

    Database Connection Information
    
         Database server        = DB2/LINUX 7.2.1 
         SQL authorization ID   = DB2INST1
         Local database alias   = WASLOOP
  3. Connect to the database named was40 using the db2 connect command:
    $ db2 connect to was40

    Correct output resembles the following:

    SQL1403N The username and/or password supplied is incorrect.
     SQLSTATE=08004
  4. To disconnect from the database and log out as the DB2 instance owner, enter exit at the command prompt.