Collecting data: DB2 Client Connectivity
Collecting data for troubleshooting DB2® Client Connectivity Problems. Gathering this information before calling IBM® support helps familiarize you with the troubleshooting process and saves you time.
- Is this a reoccurring issue or the first time experiencing the issue?
- Have there been any recent changes to the instance or database cfg files?
- Have there been any recent changes to your operating system?
- Are you able to reproduce this behavior? If so, can a testcase be provided?
- Is this a production, development, or test environment?
- How many users are affected by this problem?
- What is the business impact of this problem?
- Are there other repercussions to the problem occurring?
Connectivity problems can usually be caused by:
1. Authentication problem
2. Networking problem, including improper configuration of network firewall between the DB2 client and server.
3. Wrong permission settings of DB2 files.
4. The DB2 instance is not listening on the port number or listening on a wrong port number.
5. The DB2 node or database alias is incorrectly cataloged.
Connectivity problems are usually with remote clients, so before you start to collect any DB2 diagnostic information, you need to make sure there is no networking problem. Run the ping command to make sure the server is accessible from the client:
If the ping command returns successfully, you can then run the netstat command to verify that DB2 instance is listening on the port number that is uniquely specified by the DBM CFG parameter SVCENAME:
netstat -an | grep <unique DB2 port#>
No matter where the client is, the following diagnostic information will be needed to diagnose the connectivity problem:
1) db2support.zip on both client and server
db2support . -o db2support.client.zip
db2support . -o db2support.server.zip
2) DB2 trace on the connectivity problem from both client and server:
a) Turn on the trace:
db2trc on -f client.dmp
db2trc on -f server.dmp
b) Recreate the connectivity problem.
c) As soon as the error occurs, turn off the trace on both client and server:
d) Format the trace:
db2trc flw client.dmp client.flw
db2trc fmt -c client.dmp client_drda.fmt
db2trc fmt server.dmp server.fmt
db2trc flw server.dmp server.flw
db2trc fmt -c server.dmp server_drda.fmt
If the problem is with the networking layer, a protocol trace will be helpful for diagnosing the problem. For TCP/IP protocol, you can use tcpdump command to collect the protocol trace for both AIX and Linux, snoop for Solaris, and tracert.exe for Windows. For the information about the syntax of tcpdump and snoop, you can go to its man page (man tcpdump or man snoop) on the system. The syntax of tracert.exe is as follows:
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name
Submitting information to IBM Support
Once you have collected your information, you can begin Problem Determination through the product Support web page, or simply submit the diagnostic information to IBM support. Use the document below for submitting information to IBM Support.
Submitting diagnostic information to IBM Technical Support for problem determination
More support for:
DB2 for Linux, UNIX and Windows
Connectivity - TCP/IP Protocol
Software version: 9.7, 9.8, 10.1, 10.5
Operating system(s): AIX, HP-UX, Linux, Solaris, Windows
Software edition: Enterprise Server, Personal, Personal Developer's, Workgroup Server
Reference #: 1286651
Modified date: 04 June 2015
Translate this page: