The following section covers some of the common problems you may encounter while installing DB2, creating an instance, or using a DB2 database.
The following section covers some of the common problems you may encounter when you install DB2.
9.1.1. When I try to run db2setup, I get the following error: DBI1503E An error was encountered when opening or writing to file, "/tmp/.dbinst.swp".
DB2 issues this error when it can't find the pdksh or ksh shells. This has probably occurred because you did not install the pdksh package for your distribution. See Section 3 for more details on installing the pdksh package for your Linux distribution.
9.1.2. When I try to run db2setup, I get the following error: ./db2inst: error while loading shared libraries: libncurses.so.4: cannot open shared object file: No such file or directory
DB2 issues this error when it can't find the libncurses.so.4 library. Red Hat 7 does not include this level of the library in their standard ncurses-5.1-2 package, requiring that you install the ncurses4-5.0-2 library for backwards compatibility.
9.1.3. After creating a DB2 instance, I installed the Application Development Client, but I can't use that instance to create DB2 applications.
When you add the Application Development Client after you initially install DB2 and create a DB2 instance, your existing DB2 instance won't recognize the db2 prep command. Instead, DB2 returns the following error: DB21051E The command is not supported for this environment.
The problem is that when you install a new DB2 component, DB2 does not automatically update existing DB2 instances to include links to the new libraries and executables. To update an existing DB2 instance, use the db2iupdt command as root:
bash# /usr/IBMdb2/V7.1/instance/db2iupdt instance-name |
bash# /usr/IBMdb2/V7.1/instance/db2iupdt -e |
The following section covers some of the common problems you may encounter when you create a DB2 instance.
DB2 often fails to create an instance because you became root by issuing the command bash$ su root rather than bash$ su -l root, which uses the environment settings for the root account. Check the contents of the DB2 install log in /tmp/db2setup.log. If the installer has issued the following error message:
DBI1517E An attempt to execute a command in a subprocess failed.
Explanation: An error was detected when attempting to execute a command in a subprocess. One of the
following problems occurred:
o The command does not exist.
o Incomplete command search path.
o Incorrect access permissions on the command.
o System resource problem. |
PATH is normally set correctly for you if you log in as root, or issue the command bash$ su -l root to become root. You can add /usr/sbin to the PATH environment variable by issuing the following command at the terminal prompt, or including it in /root/.bashrc:
export PATH=$PATH:/usr/sbin |
9.2.2. db2setup indicated that it successfully created an instance, but I checked /tmp/db2install.log and it contains the message DBI1766W Cannot change the secondary group list of "" (Caldera OpenLinux 2.4).
This is one area where DB2 and Caldera OpenLinux don't work well together. Fix this by manually adding each instance user ID to the group you defined during instance creation. Here's the full help from the IBM DB2 Message Reference:
DBI1766W Cannot change the secondary group list of
"".
Explanation: A code, "", is returned when attempting to
change the secondary group list of the given user ID. One of the
following situations has occurred:
o NIS is running.
o One or more processes are currently being executed under the
given user ID.
User Response: You must add the group ID, "", to the
secondary group list of the user ID, "", so that the
Adminstration Server can function properly.
o If there happens to be any process run under the given user
ID, terminate all of these processes and follow the
instructions above to setup the secondary group list of this
user ID.
o If you are running this command on an NIS client, try the
above instructions to setup the secondary group list of this
user ID on your NIS server. |
The following section covers some of the common problems you may encounter when you use a DB2 database.
bash$ db2 connect to sample Database Connection Information Database server = DB2/LINUX 7.1.0 SQL authorization ID = userID Local database alias = SAMPLE |
bash$ db2 CONNECT TO sample USER userID Enter current password for userID: SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004 |
Hey! I said I wasn't going to include any DB2 Version 6.1 information! Oh well, this is one of the most frequently asked questions about 6.1, so here's a short answer: you need to install a recent DB2 FixPack. The initial release of DB2 Version 6.1 ran into incompatibilities with distributions built on glibc 2.1. For a full description of the problem, and the correct install procedure, refer to IBM Support document 1000814: db2start hangs on Linux distributions built with glibc 2.1.
9.3.2. I'm using DB2 PE 7.1 on linux (RH 6.0), and I'm having problems when trying to connect with my username and password. I can connect successfully to the database with the default user ID:
bash$ db2 connect to sample Database Connection Information Database server = DB2/LINUX 7.1.0 SQL authorization ID = userID Local database alias = SAMPLE |
bash$ db2 CONNECT TO sample USER userID Enter current password for userID: SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004 |
Check the ownership and permissions on the db2ckpw program. They should look like this:
bash$ ls -al ~/sqllib/security/db2ckpw -rwsr-s--x 1 root build 15989 Oct 17 07:22 sqllib/security/db2ckpw* |
bash# chown root db2ckpw bash# chmod ug+s db2ckpw |
The number of connections that DB2 can support depends on three #define variables included in the kernel source header files. Following the description of these variables is a table listing the default values by distribution. The table includes the values of these variables in the updated kernel packages for each distribution.
This variable, defined in /usr/src/linux/include/asm/shmparam.h, determines the number of shared memory segment identifiers available to Linux. The default value for _SHM_ID_BITS in the kernel source is 7, which allows for a total of 2^7, or 128, shared memory segment identifiers.
On a single-processor machine, DB2 itself uses a set number (~15) of shared memory segment identifiers. On a machine with multiple processors, DB2 also requires one shared memory segment identifier per agent to take advantage of the Fast Communication Manager (FCM) feature of DB2. Because each DB2 connection requires one agent per processor, on a quad-processor machine the default value of _SHM_ID_BITS allows less than 32 simultaneous connections to a DB2 instance.
If you recompile the kernel yourself, you should be able to safely increase this value to 9.
This variable, defined in /usr/src/linux/include/linux/tasks.h, determines the number of simultaneous processes that Linux supports. A second variable, MAX_TASKS_PER_USER, is defined as NR_TASKS/2. Since DB2 instances are treated as users by Linux, and each connection uses a single process, the maximum number of connections per instance is capped at the value of NR_TASKS/2.
The default value for NR_TASKS in the kernel source is 512, allowing a maximum of 256 simultaneous connections to a single DB2 instance. DB2 itself requires a few connections for overhead processes. If you recompile the kernel yourself, you should increase this value to something like 2048. The stock kernels shipped with the Red Hat, SuSE, and TurboLinux distributions increase the value of NR_TASKS to 2560 or above. However, Caldera OpenLinux eDesktop 2.4 ships with a kernel in which NR_TASKS is set to the default value of 512. Caldera users should increase the value of this variable and recompile the kernel.
This variable, defined in /usr/src/linux/include/linux/sem.h, determines the number of semaphore identifiers that Linux supports. This variable is particularly important on symmetric multi-processing (SMP) machines. A unique semaphor identifier is required for each processor per agent (or connection); therefore, on a quad-processor machine, four semaphore identifiers are required per connection.
The default value for SEMMNI in the kernel source is 128, which, on a quad-processor machine, will only allow 32 simultaneous connections to a DB2 instance. If you recompile the kernel yourself, increase this value to something like 1024.
Table 2. Default kernel parameter values, by distribution
| Kernel Parameter | Kernel Source | Caldera OpenLinux eDesktop 2.4 | Caldera OpenLinux eServer 2.3 | Red Hat 6.2 | SuSE 6.2 | SuSE 6.3 | TurboLinux 6.0 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| _SHM_ID_BITS | 7 | 7 | 7 |
| Unknown | Unknown |
| ||||||||||
| NR_TASKS | 512 | 512 | 512 |
| Unknown | Unknown |
| ||||||||||
| SEMMNI | 128 | 128 | 128 |
| Unknown | Unknown |
|
9.3.4. When I start the DB2 Control Center, I get a message box with the error SQL1042C An unexpected system error occurred.
On most systems, this error occurs only the first time you start the Control Center. Note that the message box may be mostly covered up by the pretty DB2 splash screen; if this is the case, you have to move the error message window down and press the "Close" button. The Control Center then starts correctly, and you should not get the error message again.
If the Control Center displays an empty "Systems" folder, you might need to catalog the DB2 Administration Server manually for the local instance from which you are trying to run the Control Center. This assumes that you have created the DB2 Administration Server instance before starting the Control Center.
To catalog the DB2 Administration Server, issue the following command:
bash$ db2 catalog admin local node machine-name instance Administration-Server-name system machine-name ostype linux |
9.3.6. When I try to start the DB2 Control Center, I get the following message at the console: Xlib: connection to "localhost:0.0" refused by server
This normally indicates an X permissions problem that occurs when you log on as one user, then su to the DB2 instance owner so that you can start the DB2 Control Center. By default, most X servers do not recognize 'localhost' as a client that is allowed to initiate an X app on your display; it will only recognize your real hostname. If xauth is set up, then it will complain if a user ID other than the one that started X tries to invoke an X application.There are a few things you can try:
Before su'ing to the DB2 instance owner, issue the command bash$ xhost +localhost: this tells your X server that 'localhost' is allowed to start X apps on your display. Then su to the DB2 instance owner and start the Control Center.
Log out completely, then log on directly as the DB2 instance owner and start the Control Center. You may still have to issue the command bash$ xhost +localhost before the Control Center will start--recent distributions have added this extra level of security.
Look into the xauth command and add your primary user ID's ~/.Xauthority file to your DB2 instance owner's xauth authority database. I believe it's the xauth merge command that you want.
9.3.7. When I start the DB2 Control Center, I get a message box with the error SQL1042C An unexpected system error occurred.
On most systems, this error occurs only the first time you start the Control Center. Note that the message box may be mostly covered up by the pretty DB2 splash screen; if this is the case, you have to move the error message window down and press the "Close" button. The Control Center then starts correctly, and you should not get the error message again.
9.3.8. When I try to start the DB2 Control Center with the db2cc command, the splash screen comes up, then disappears.
On Caldera, the Control Center didn't work for me until I added the instance user IDs to the appropriate groups. For more information, see Section 3.1.3.1.
Ensure that you have installed the IBM Developer Kit for Java, and that the directory containing the jre or java executable is in your path. If you issue the command
bash$ java -fullversion |
9.3.9. When I run any db2 commands, part of the output is Welcome to your OpenLinux system!. How do I change this? (Caldera OpenLinux 2.4)
Caldera OpenLinux includes this annoying message as part of their default login. For instructions on how to remove or modify this output, see Section 3.1.3.3.