今天上午，经过了长假的休息，数据库也开始不安分了，alert日志里出来了一个警告：

Fri Oct  9 10:38:11 2009
WARNING: inbound connection timed out (ORA-3136)

这个错误挺常见的，如果偶然发生，一般没什么问题，有时候是客户端的防火墙阻止了连接，和oracle没关系。sqlnet.log记录的信息如下：

***********************************************************************
Fatal NI connect error 12170.

  VERSION INFORMATION:
 TNS for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Production
 TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Production
 Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Production
  Time: 09-OCT-2009 10:38:11
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    TNS-12535: TNS:operation timed out
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.16.86.86)(PORT=1876))

这个错误的发生就是因为用户验证时间超过了SQLNET.INBOUND_CONNECT_TIMEOUT参数设定的时间导致的，10.2.0.1之前的版本该参数是默认为0，10.2.0.1开始这个参数的值被设置为60秒，验证时间超过了60秒就会在alert日志记录这个警告。设置该参数的目的是为了防止Denial of Service (DoS)恶意攻击。

DB1@/u01/admin/erpdb/bdump>lsnrctl

LSNRCTL for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Production on 09-OCT-2009 10:49:18

Copyright (c) 1991, 2006, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> show inbound_connect_timeout
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER parameter "inbound_connect_timeout" set to 60
The command completed successfully
LSNRCTL> exit

如果是频繁出现，可以通过修改sqlnet.ora文件的SQLNET.INBOUND_CONNECT_TIMEOUT和listener.ora文件的INBOUND_CONNECT_TIMEOUT_<listenername>参数来避免这个问题。 Metalink上Doc ID:  465043.1相信描述了如何解决这个问题，引用如下：

There can be three main reasons for this error -

1. Server gets a connection request from a malicious client which is not supposed to connect to the database , in which case the error thrown is the correct behavior. You can get the client address for which the error was thrown via sqlnet log file.
2. The server receives a valid client connection request but the client takes a long time to authenticate more than the default 60 seconds.
3. The DB server is heavily loaded due to which it cannot finish the client logon within the timeout specified.

To understand what is causing this issue, following checks can be done

The default value of 60 seconds is good enough in most conditions for the database server to authenticate a client connection. If it is taking longer, then its worth checking all the below points before going for the workaround:

1. Check whether local connection on the database server is successful & quick.
2. If local connections are quick ,then check for underlying network delay with the help of your network administrator.
3. Check whether your Database performance has degraded in anyway.
4. Check alert log for any critical errors for eg, ORA-600 or ORA-7445 and get them  resolved first.
These critical errors might have triggered the slowness of the database server.

As a workaround to avoid only this warning messages, you can set the parameters SQLNET.INBOUND_CONNECT_TIMEOUT
and
 INBOUND_CONNECT_TIMEOUT_<listenername>
to the value more than 60.

For e.g 120. So that the client will have more time to provide the authentication information to the database. You may have to further tune these parameter values according to your setup.

To set these parameter -

1. In server side sqlnet.ora file add

SQLNET.INBOUND_CONNECT_TIMEOUT

For e.g

SQLNET.INBOUND_CONNECT_TIMEOUT = 120

2. In listener.ora file -

INBOUND_CONNECT_TIMEOUT_<listenername> = 110

For e.g if the listener name is LISTENER then -  

INBOUND_CONNECT_TIMEOUT_LISTENER = 110

 
How to check whether inbound timout is active for the listener and database server

For eg. INBOUND_CONNECT_TIMEOUT_<listener_name> =4

You can check whether the parameter is active or not by simply doing telnet to the listener port.
$ telnet <database server IP> <listener port>
for eg.

$ telnet 192.168.12.13 1521

The telnet session should disconnect after 4 seconds which indicates that the inbound connection timeout for the listener is active.

To check whether database server sqlnet.inbound_connect_timeout is active:
Eg.

sqlnet.inbound_connect_timeout =5

a. For Dedicated server setup, enable the support level sqlnet server tracing will show the timeout value as below:

niotns: Enabling CTO, value=5000 (milliseconds) <== 5 seconds
niotns: Not enabling dead connection detection.
niotns: listener bequeathed shadow coming to life...


b. For shared Server setup,
$ telnet <database server IP> <dispatcher port>
For eg.

$ telnet 192.168.12.13  51658

The telnet session should disconnect after 5 seconds which indicates that the sqlnet.inbound_connect_timeout is active.