oracle中ORA-3136,ORA-609-mysql教程

本文章详细的介绍了关于oracle中ORA-3136,ORA-609方法，有需要的朋友可以参考一下本文章哦。

Fatal NI connect error 12170.

VERSION INFORMATION:
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Time: 01-11月-2011 16:46:57
Tracing not turned on.
Tns error struct:
ns main err code: 12535

TNS-12535: TNS: 操作超时
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=192.168.3.53)(PORT=2950))
WARNING: inbound connection timed out (ORA-3136)

Fatal NI connect error 12560, connecting to:
(LOCAL=NO)

VERSION INFORMATION:
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Time: 09-11月-2011 11:22:32
Tracing not turned on.
Tns error struct:
ns main err code: 12560

TNS-12560: TNS: 协议适配器错误
ns secondary err code: 0
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
opiodr aborting process unknown ospid (21388) as a result of ORA-609
Wed Nov 09 11:22:49 2011

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种可能性：

There can be three main reasons for this error -

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

有可能是数据库服务器压力大，也有可能是应用服务器压力大，只要是这60秒内这个认证过程没有完成，就会报这个错误。

跑awr,发现shared pool撑的比较大，library cache latch和shared pool latch 与swap发生置换，page in增高 cpu的wio增高，现象和我们系统的几次情况完全一样，经过几次调优，我们分析主要是这么个流程 ：1 ，分析业务连接，主要通过监听日志和交换机防火墙，确定每秒连接次数，确定是哪些业务连接过来，经过确认有业务连接池有问题，在被其他站点爬虫抓取之后，压力非常大，限制连接池，业务连接问题解决； 分析是否无绑定变量，经过分析，系统代码良好，全部使用绑定变量 ； 3，分析shared pool配置，经查，使用自动内存配置，10g的不能解决的问题就是当自动配置后，会有bug造成池不断增大，修改为手动配置， 4,分析机器内存参数配置，发现剩余内存较小，设置内存保留，确保当系统压力大时，系统仍能分配出内存，而不是把内存使用为cache，oracle 反而去从swap中取地址造成系统无响应造成报错ORA-01017，分析os内存分配主要看共享内存和各进程内存，发现耗费内存的主要还是共享池撑的过大，降低之，os的cache耗费过高，设置为directio后，降低cache使用内存，之后此情况没有再出现过。如performance所说，小荷你还得看看机器中内存到底是被什么给消耗掉了，pin住sga不是最关键的，如果内存够用，sga被转到swap的概率很低，而且很快就会回来，所以我觉得还是得分析到底内存被用在哪里了。

swap严重

与swap发生置换，page in增高->hdisk0繁忙100%->整体系统负载高->fork服务器进程失败->ora-3136错误
与swap发生置换，page in增高->hdisk0繁忙100%->整体系统负载高->library cache latch和shared pool latch

但是本案例没有找到swap很高的原因