当使用错误的用户名或密码登陆数据库时，会提示如下报错内容：
bash-4.1$ sqlplus a/a@test
SQL*Plus: Release 10.2.0.4.0 - Production on Sun Sep 15 17:06:51 2013
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
ERROR:
ORA-01017: invalid username/password; logon denied
Enter user-name:
此时不要做任何操作，然后等待一分钟，从alert日志中可以查到如下内容：
WARNING: inbound connection timed out (ORA-3136)
从MOS的465043.1：Troubleshooting ORA-3136: WARNING Inbound Connection Timed Out，这篇文章找到一些端倪：
这个报错指出客户端连接没有在规定的时间内通过认证，这个时间是由SQLNET.INBOUND_CONNECT_TIMEOUT参数决定的。
此时在sqlnet.log($ORACLE_HOME/network/log)中可以看到有ORA-12170或TNS-12535的报错(服务端)。信息中应该包含连接的客户端地址，这将有助于判断这个问题。但是一些应用或者JDBC thin driver的应用可能没有此类信息。默认情况下，在11g以后的版本中，sqlnet.log日志不会产生。
从10.2.0.1以后的版本，参数SQLNET.INBOUND_CONNECT_TIMEOUT的默认设置是60秒。如果客户端没能在60秒内完成验证，在alert日志中就会出现Warning信息，客户端连接被终止。
这种超时限制主要用于阻止Dos(Denial of Service)服务攻击，防止大量的恶意客户端请求涌向数据库服务器，以消耗其资源。
对于这种报错的几种可能的原因：
1. 服务器接收到来自于不支持连接此数据库的大量客户端恶意请求。这种情况下，需要抛出这种错误以及相应的行为。通过sqlnet.log中记录的客户端地址，找到错误根源。
2. 服务器接收到一个合法的客户端连接请求，但是客户端花费了比默认60秒更长的时间来完成验证。
3. 数据库服务器当前负载很重，以至于不能在规定的时间内完成客户端登陆验证。
为了了解这种错误的原因，可能需要如下的检查：
默认60秒的值在大多数数据库服务器验证客户端请求的情况下是合适的。如果这个过程时间太长，那么在寻找解决方法之前可以先检查如下选项：
1. 检查数据库服务器的本地连接是否正常，速度是否合适。
2. 如果本地连接比较快，那么可以在网络管理员的帮助下检查网络延迟。
3. 检查数据库性能是否下降。
4. 检查alert日志中是否有其它严重的报错，例如ORA-600或ORA-7445，如果有，那么先解决它们。
这些严重的报错可能引发数据库服务器的缓慢。
为了解决这个问题，通常有必要增加监听和数据库的INBOUND CONNECT TIMEOUT的取值。通常建议设置数据库取值(sqlnet.ora)比监听取值(listener.ora)略高。验证过程更依赖于数据库而不是监听。
可以遵照如下说明并重启监听，来设置这些参数取值为大于默认60秒。不需要重启数据库：
编辑服务端的sqlnet.ora文件，添加这个参数：
SQLNET.INBOUND_CONNECT_TIMEOUT=<n>
<n>代表秒。
例如：
SQLNET.INBOUND_CONNECT_TIMEOUT = 120
编辑listener.ora文件，添加这个参数：
INBOUND_CONNECT_TIMEOUT_<listenername> = <n>
<n>代表超时的秒。
例如：
INBOUND_CONNECT_TIMEOUT_LISTENER = 110
从10.2.0.1以后，INBOUND_CONNECT_TIMEOUT_<listenername>默认值是60秒。之前的版本，默认值是0或关闭。
如何检查监听和数据库服务器的inbound超时：
例如INBOUND_CONNECT_TIMEOUT_<listener_name> =110，可以通过telnet监听端口来检查这个参数是否生效。
$ telnet <database server IP> <listener port>
例如：
$ telnet 123.23.23.23 1521
telnet的session应该在110秒后断开连接，那么就表明监听的inbound连接超时生效。
另外，也可以检查LSNRCTL提示：
LSNRCTL>set current_listener <listener_name>
LSNRCTL>show inbound_connect_timeout
如何检查数据库服务器的SQLNET.INBOUND_CONNECT_TIMEOUT参数生效：
例如：SQLNET.INBOUND_CONNECT_TIMEOUT=120
a. 对于专享服务器，打开support level sqlnet server tracing，将会展示如下超时参数值：
niotns: Enabling CTO, value=120000 (milliseconds) <== 120 seconds
niotns: Not enabling dead connection detection.
niotns: listener bequeathed shadow coming to life...
b. 对于共享服务器，
$ telnet <database server IP> <dispatcher port>
例如：
$ telnet 123.23.23.23 51658
telnet的session将会在120秒后断开连接，表明sqlnet.inbound_connect_timeout参数生效。
如下两个方式还可以继续参考关于这个3136问题：
a. Client and matching server traces generated at support level.
Note 395525.1 How to Enable Oracle Net Client,Server,Listener,Kerberos and External procedure Tracing from Net Manager (netmgr):
Note 374116.1 How to Match Oracle Net Client and Server Trace Files
b. Upload sqlnet.ora, listener.ora Sqlnet.log, & Alert_<sid>.log from database server
不过@eygle也指出(http://www.eygle.com/archives/2006/07/sqlnet_inbound_connect_timeout.html)，修改监听参数后不用重启监听，只需要reload。这个有待尝试。另外小荷在(http://www.oracleblog.org/working-case/deal-with-ora3136/)也讨论过这个问题。总结来讲，3136的报错可能是客户端输入错误验证信息，也可能是遭受到Dos攻击，或者有可能是数据库负载较严重的情况下客户端的连接也会出现这个报错。