Партнёры:
Хостинг:
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.
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.
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.
If you did not remove the default DB2 user IDs created by SuSE Linux before installing DB2 (see Section 3.6), the DB2 Create Instance panel places the corresponding user ID in the "User ID" field. This can cause a problem when you change the value of the User Name field to reflect the name of the new instance, because the value of the "User ID" still reflects the original user name.
Ensure that you select the "Use default UID" check box to automatically associate the new user name with its corresponding user ID.
If you did not remove the default DB2 user IDs created by SuSE Linux before installing DB2 (see Section 3.6), the DB2 Create Instance panel places the corresponding group ID in the Group ID field. This can cause a problem when you change the value of the Group Name field to reflect the name of the new instance, because the value of the Group ID still reflects the original group name.
Ensure that you select the "Use default GID" check box to automatically associate the new group name with its corresponding group ID.
If you did not remove the default DB2 user IDs created by SuSE Linux before installing DB2 (see Section 3.6), the default user name already exists and was created in the /usr/lib/db2/ directory. To change the home directory of your new DB2 instance, you must manually specify the location of the new instance. The default home directory is /home/.
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 |
When you create an instance, as described in Section 6, DB2 copies selected files from /usr/IBMdb2/V7.1/bin into the $HOME/sqllib/bin directory of the instance. DB2 sets the appropriate permissions on the copies of the files in the instance directory.
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 |
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 |
You probably need to adjust some kernel parameters. For more information, see Section 10.
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.
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 |
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.
Claus Reiner contributed the following procedure:
Preparing DB2 for AS/400 to accept connections
AS/400 has a special service that must be run and other things that need to be prepared:
Name the database and make a *LOCAL entry Command WRKRDBDIRE. There should be an entry with a remote location name of *LOCAL. The relational database name specified with that entry is the external name of the AS/400 database. Typically this is the same name as the system name.
Set the code page to 37. For the user that connects, change the CCSID parameter from *SYSVAL to 37, or change it system-wide:
CHGUSRPRF USRPRF(user) CCSID(37) |
CHGSYSVAL SYSVAL(QCCSID) VALUE(37) |
Start a service to listen on port 446. To start the service once:
STRTCPSVR SERVER(*DDM) |
CHGDDMTCPA AUTOSTART(*YES) |
Create a NULLID collection by issuing the following SQL statement:
CREATE COLLECTION NULLID |
Possibly create a collection for the user ID to connect with:
CREATE COLLECTION userid |
Preparing DB2 Connect for Linux to connect to an AS/400 database
On the Linux side, you need to perform the following steps:
Catalog the remote node (the AS/400) with OSTYPE OS400:
bash$ db2 CATALOG TCPIP NODE as400 REMOTE as400 \
SERVER 446 REMOTE_DATABASE as400_dbname \
OSTYPE os400
|
Catalog the remote database in DCS:
bash$ db2 CATALOG DCS DATABASE as400_dbname AS as400_dbname |
Catalog the remote database:
bash$ db2 CATALOG DATABASE as400_dbname AS as400_dbname \
AT NODE as400 AUTHENTICATION DCS
|
The following section covers some of the common problems you may encounter trying to start the DB2 Control Center.
On some systems, for unknown reasons, issuing the db2cc command will not start the Control Center. You can often get the DB2 Control Center to start by explicitly starting a DB2 JDBC server on a specified port, then issuing the db2cc command with the port number. The following example starts the DB2 JDBC server and DB2 Control Center on port 6799:
bash$ db2jstrt 6799 bash$ db2cc 6799 |
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.
Red Hat 7.1 enabled a floating stack feature in the glibc library that breaks the IBM JDK 1.1.8. Other distributions might follow their lead.
Set the LD_ASSUME_KERNEL environment variable to 2.2.5 before running the DB2 Control Center or your Java application:
bash$ export LD_ASSUME_KERNEL=2.2.5 bash$ db2set DB2ENVLIST=LD_ASSUME_KERNEL |
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 |
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.
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.
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 |
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |