Question

db2 报SQLSTATE=08001 是什么原因？

Answer 1

这种问题一般的原因：
1.DB2COMM=TCPIP
2.数据库故障
3.端口号被禁用

解决方案：

1.看看端口号有没有配置正确，看一下配置参数svcename跟services文件中配置的db2端口号是否一致，windows一般用50000，unix/linux一般用60000。
2.连接出错首先看看服务器ip 和端口写对没有。
ip如果没错就要看看服务器的db2服务端口对不对。另外对于服务器下面这些也要注意。

检查服务器的配置情况如下：

验证存在的DB2数据库
db2 list db directory
db2 list db directory show detail
验证实例使用的通讯协议，查看DB2COMM变量
db2set -all
查看数据库管理器的配置，查看SVCENAME（特指tcpip协议）
db2 get dbm cfg
查看/etc/services中，有无与上面对应SVCENAME的端口，例如：
db2cDB2 50000/tcp

要确认服务器是否在监听，可以用netstat -an 来查看端口是否处于LISTEN状态。

Answer 2

通信协议出错。
下面是DB2 infocenter 上的消息：
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.messages.sql.doc%2Fdoc%2Fmsql30081n.html&resultof=%22sql30081%22

SQL30081N

A communication error has been detected. Communication protocol being used: protocol. Communication API being used: interface. Location where the error was detected: location. Communication function detecting the error: function. Protocol specific error code(s): rc1, rc2, rc3.
Explanation

An error has been detected by the communication subsystem.

The following is a description of the token values:

protocol, location

Communication protocol used and information that uniquely identifies the node that detected the error. If the location information is not available at the time that the error occurred, then the location token is not filled in. Valid token values are:

protocol TCP/IP; location is the IPv4 or IPv6 address.
protocol APPC; location is the fully qualified LU name (networkID.LUname).
protocol MQ; location is the MQ queue name.
protocol SOAP, SSL, SOCKS, HTTP; location is the Internet address in dot notation.

interface

The application programming interface used to invoke the above protocol services. Valid token values are: SOCKETS, SOCKS, CPI-C, MQI-CLIENT, GSKit, HTTP.
function

The name of the communication subsystem function that returned the error code or codes.

If protocol is TCP/IP:

Reason codes rc1, rc2, rc3 represent:
If present, rc1 contains the errno returned by the TCP/IP function. On Windows, this is a WSA errno.
If present, rc2 contains the h_errno value returned by a TCP/IP name resolution function. On Windows, this is a WSA error number.
If rc3 is present and contains "0", the remote side has terminated the connection. If the error was received on the client, then the remote side could be a server or gateway. If the error was received on the gateway, the remote side could be the client or server.

If protocol = TCP/IP, rc1=*, rc2=*, and rc3=0, possible causes include:
The database agent at the server was forced off by the system administrator.
A database agent could not be started at the server because a memory limitation was reached on the system.
The connection might have been closed by the remote server at the TCP/IP level.
The database agent at the server was terminated due to an abnormal termination of a key database manager process.

On Windows, if protocol = TCP/IP, function = WSAStartup, and rc1 = 0, then rc2 contains the Windows Sockets Specification version level requested by DB2, and rc3 contains the Windows Sockets Specification version level supported by the Windows Sockets DLL. Cause: There was a version level mismatch.

If protocol = TCP/IP, function = connect, rc1 = ECONNREFUSED/WSAECONNREFUSED, AIX (79), Windows (10061), linux (111), SUN (146), HP (239), the attempt to connect was rejected. Possible causes:
The remote database server has not been cataloged correctly at the client. In a client-gateway-server scenario, ensure the host entries are cataloged correctly on the gateway.
The database manager configuration file at the server has not been configured properly with the proper communication parameters. Check that the SVCENAME database manager configuration parameter has been configured properly with the TCP/IP service name or port number and that the port number is unique. If database manager configuration parameters have been updated at the server, the database manager must be stopped and re-started for the changes to take effect. There might be a mismatch between the TCP/IP service name or port number specified on the server and on the client. Ensure the service name maps to the correct port number by checking the services file. You can check this by reading the services file or checking the output from running the command "netstat -a".
A firewall at the remote database server has prevented the connection from being established. Verify that the firewall is properly configured to accept connection requests from the client.
The DB2COMM environment variable at the server does not specify the communication protocol used by the client. Check that TCPIP has been specified. Issue db2set to see what has already been set. Run the command "db2set DB2COMM = TCPIP" to set the value.
The database manager at the server has not been started, or has not been started successfully, or has gone down. The server should have returned SQL1063N, and not SQL5043N. If you set the database manager configuration parameter DIAGLEVEL to 4 using the command "db2 update dbm cfg using diaglevel 4" prior to issuing the "db2start" command, then the administration notification log will provide detailed information on which protocols were started successfully. Check the administration notification log.
The server might be too busy to handle the volume of incoming connections at this time.
Network failure, contact your network administrator. You can try a test using the protocol tester, pctt, to verify this is not a DB2 problem.

If protocol = TCP/IP, function = connect, rc1 = ETIMEDOUT/WSAETIMEDOUT, AIX (78), Windows (10060), linux (110), SUN (145), HP (238), attempt to connect timed out before a connection was made. Possible causes:
An incorrect host name or IP address was cataloged in the hostname field of the node directory on the client and/or gateway.
The network is slow, or the server might be too busy to respond to the connect request within a reasonable amount of time, you might need to adjust your system TCP connect timeout value and/or the DB2TCP_CLIENT_CONTIMEOUT value.

If protocol = TCP/IP, function = recv, rc1 = ECONNRESET/WSAECONNRESET, AIX (73), Windows (10054), linux (104), SUN (131), HP (232), the connection was reset by the remote side executing a "hard" or "abortive" close. Possible causes:
The connection might have been closed by the remote gateway or server at the TCP/IP level (eg. firewall problem, power failure, network failure).
Client side connection pooling is enabled and is not handling connection failures. Code the application to retry a connection if a failure is received when connecting to the database and connection pooling is enabled.
Might have been caused by a thread timeout on the host machine. Check the system log on the host for the presence of the IDTHTOIN message. Adjust the setting if applicable. If this cannot be adjusted, either disable connection pooling on the gateway, or ensure all objects are properly closed (eg. cursors with hold when the application completes its operation).
The database agent at the server was forced off by the database administrator.
The database agent at the server was terminated due to an abnormal termination of a key database manager process.

If protocol = TCP/IP, function = recv, rc1 = ETIMEDOUT/WSAETIMEDOUT, AIX (78), Windows (10060), linux (110), SUN (145), HP (238), the connection was dropped because the remote system failed to respond. Possible causes:
SQLCancel() was called from a CLI application because the application set the Query Timeout value or there was an explicit cancel request. Adjust the Query Timeout value set by the application. If this is not possible, adjust the QueryTimeoutInterval setting in the db2cli.ini file. Use QueryTimeoutInterval=0 (no timeout) in the db2cli.ini file to test whether QueryTimeout is the cause of your application's failure. The failure of an existing connection is expected in this scenario.
The network is slow, or the server might be too busy to respond to the recv request within a reasonable amount of time, you might need to adjust your system TCP recv timeout value.

If protocol = TCP/IP, function = selectForConnectTimeout, rc1 = EINPROGRESS/0, AIX (55), Windows (0), linux (115), SUN (150), HP (245), the connect request timed out before it could complete successfully. Possible causes:
Either the system connect timeout or the timeout value set by DB2TCP_CLIENT_CONTIMEOUT caused the timeout. Try adjusting these values.

If protocol = TCP/IP, function = selectForRecvTimeout, rc1 is irrelevant, the recv request timed out before it could complete successfully. Possible causes:
Either the system recv timeout or the timeout value set by DB2TCP_CLIENT_RCVTIMEOUT caused the timeout. Try adjusting these values.

The list of TCP/IP errors and causes described above is not exhaustive, search the DB2 Information Center for more information about the specific TCP/IP communication error codes, searching on phrases such as "-30081 errors".

If protocol is APPC

rc1 contains the return code from the CPI-C function.
If present, rc2 contains the global errno value from the CPI-C function call.
rc3 is not applicable.

If protocol is MQ

rc1 contains the function completion code, 1 for a warning and 2 for an error.
rc2 contains the MQ-specific error code.
rc3 is not used for MQ.

If protocol is SOAP, rc1 contains the return code from the SOAP communication function.

If protocol is SSL, rc1 contains the return code from the Secure Sockets Layer (GSKit).

If protocol is SOCKS

rc1 contains the return code from the SOCKS proxy server.
rc2 contains the version (4 or 5) of the protocol.
rc3 contains the authentication method used (SOCKS v5.)

If protocol is HTTP, rc1 contains the HTTP return code from the remote HTTP server.
User response

Correct the problem indicated by the combination of reason code and token values returned, as described above.

sqlcode: -30081
sqlstate: 08001, 5UA0G, 5UA0H

Answer 3

检查你数据库的访问端口是否开放，08001通常是因为防火墙等引起不能访问数据库的端口