oracle ora 3136,一次ORA-3136的处置

比来收到一个告警，用户说数据库没法连接，但是从监控上看，oracle的背景进程已侦听进程仍是在的，没有任何的alert。

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

Thu Feb 17 09:07:31 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:31 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:31 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:32 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:32 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:32 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:32 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:32 2011

WARNING: inbound connection timed out (ORA-3136)

Thu Feb 17 09:07:32 2011

WARNING: inbound connection timed out (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种可能性：

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.

按照我的了解，总之，在oracle的侦听接管到一个来自客户真个要求，当fork到办事器历程的时刻，若是在这个过程当中发明不测，如暗码毛病，如数据库负载过重，城市参数ora-3136的报错。

由于在alertlog中除了ora-3136以外没有此外什么信息，因而拉了一份阻碍时间点摆布的awr

report来看，发现了比力紧张的问题：

1.shared pool撑的对照大：

2.library cache射中率低：

3.等候事宜中library cache的latch严峻：

4. SQL的绑定变量使用的很糟，险些没有绑定变量，某些语句近似的可以找到5000多个，只是是盘问前提中的值分歧：

SQL> select substr(SQL_TEXT,1,80),count(*) from

v$sqlarea group by substr(SQL_TEXT,1,80) order by 2

? 2? /

?

SUBSTR(SQL_TEXT,1,80)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ? COUNT(*)

----------------------------------------------------------------------------------

----------

......

?SELECT a.costareacode AS costareacode,a.costmethod AS

costmethod,a.itemcostpric? ? ? ? ?2056

?SELECT a.taxgroupcode AS taxgroupcode FROM item a? WHERE 1=1? ?

and a.itemid=10? ? ? ? ?2233

脉脉 select a.sourceorderdetailid

,a.orderid,a.orderdetailid,a.baseqty,a.orderqty,? ? ? ? ?2307

?SELECT a.creditdays AS creditdays,a.relationid AS

relationid,a.creditlevelcode? ? ? ? ? 2329

?Select count(*) as count from orderdetail where 1=1? and

orderdetailid =? 11047? ? ? ? ?2629

纠葛 select nvl(sum(a.balanceamt-a.allocamt),0) as canuseamt from

zmclrebatebalanc? ? ? ? ?4576

?SELECT a.optionvalue AS optionvalue FROM orgoption a? WHERE 1=1? ?

and a.orgid=? ? ? ? ?5458

?

597 rows selected.

?

SQL>

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锁在物理内存中。查抄后，公然发觉了些题目：

AIXTHREAD_SCOPE没有配置成S：要是利用默许的值P，oracle的进程将会map到内核进程的pool中，当oracle处于一个守候事务时，该进程就会被swap进来，此时oracle进程将会置于到另外一个内核进程上。oracle使用进程ID来提交期待的进程，以是连结统一个进程ID很主要。假如将AIXTHREAD_SCOPE设置成S，oracle进程就可以动态的map到内核进程，而不会改动进程ID。

lru_file_repage

没有配置成0：用于限定page。告知VMM，page仅用于文件型页面，而不是计较型页面(sga是较量争论型页面)。

v_pinshm没有设置成1。如果该值设置成1，那末aix的VMM将不会pin住share memory页面，因此oracle

instance将不克不及用到large page。因此该值也应当设置成1来共同使用lock_sga。

上述题目，在测试机上点窜设置后，停止一礼拜的测试，在出产体系上修改。

博文推荐：