最近收到一个告警，用户说数据库无法连接，但是从监控上看，oracle的后台进程已经侦听进程还是在的，没有任何的alert。

登录数据库，已经恢复正常，但是在数据库的alertlog中发现大量的ora-3136的报错：

时间大约是在9点开始，到9点07分结束，历时7分钟，之后就自动恢复了，后续没有报错。

而ora-3136的这个报错，在大部分情况下，我们是可以忽略的，因为这个报错一般是由于客户端由于梅雨正确的密码，连接超时导致。举个很简单的例子，我们用sqlplus user/password@tnsname，但是输入的密码是错误的，oracle提示：ORA-01017: invalid username/password; logon denied，之后，什么都别做，连接挂在那里，等一分钟之后，就可以在alertlog中看到这个报错了。

因此，ora-3136报错的一种可能性是客户端使用率错误的密码登录，但是之后没有退出连接。

但是ora-3136的报错不仅仅是这一种可能，另外还有当收到来自恶意客户端的连接，如Dos攻击，另外，还有当数据库负载比较重的时候，也会有这样的报错。具体可见metalink 《Troubleshooting ORA – 3136 WARNING Inbound Connection Timed Out [ID 465043.1]》里面说的3种可能性：

根据我的理解，总之，在oracle的侦听接受到一个来自客户端的请求，当fork到服务器进程的时候，如果在这个过程中发现意外，如密码错误，如数据库负载太重，都会参数ora-3136的报错。

由于在alertlog中除了ora-3136之外没有别的什么信息，于是拉了一份故障时间点左右的awr report来看，发现了比较严重的问题：
1.shared pool撑的比较大：

2.library cache命中率低：

3.等待事件中library cache的latch严重：

4. SQL的绑定变量使用的很糟糕，几乎没有绑定变量，某些语句类似的可以找到5000多个，仅仅是查询条件中的值不同：

ok，到这里，我们从awrreport中可以暂时的理出一条线索：sql没有很好的绑定变量->需要大量的library cache内存->申请内存的时候，可能机器负载高，导致ora3136的报错。

我们继续结合系统层面的NMON数据来看系统当时的负载情况：
1.八点半到九点多的那段时间CPU中的IO较高：

2. 八点半到九点多那段时间的hdisk0很忙，几乎到100%：

由于hdisk0和hdisk1是属于local disk，hdisk4和hdisk5是san storage。而local disk除了用于本地的一些文件系统的使用，还有用于swap空间。我们继续去看page in和page out的情况。

3. 八点半到九点多那段时间有大量的page in：

因此，我们再次可以进一步的推论：由于需要大量的library cache，数据库向内存申请空间，由于空间不够，或者配置的原因，申请的空间需要向swap空间发生置换，因此发生page in，而在swap空间中的library cache又远远比不上在物理内存内的效率，且hdisk0的繁忙程度为100%。

综上，造成上述的故障：SQL没有很好的绑定变量->需要大量的library cache->申请library cache内存的时候，与swap发生置换，page in增高->hdisk0繁忙100%->整体系统负载高->fork服务器进程失败->ora-3136报错。

因为该机器的物理内存有40G，而我们配置的SGA+PGA还不到20G，有这样大的pipo，我们怀疑是不是有些aix的配置没有正确，同时我们也希望设置lock_sga的参数，把sga锁在物理内存中。检查后，果然发现了些问题：

上述问题，在测试机上修改设置后，进行一星期的测试，在生产系统上修改。

http://www.oracleblog.org/working-case/deal-with-ora3136/