关于ORA-3136的处理思路

整理自网络。。。。
在告警日志里出现了大量ORA-3136的报错,于是mos上查看:
从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,如果有,那么先解决它们,这些严重的报错可能引发数据库服务器的缓慢。
这是和网络连接相关的一个错误,Metalink上给出了如下的解决方案:
1.set INBOUND_CONNECT_TIMEOUT_<listenername>=0 in listener.ora
2. set SQLNET.INBOUND_CONNECT_TIMEOUT = 0 in sqlnet.ora of  server .
3. stop and start both listener and database.
4. Now try to connect to DB and observe the behaviour
详细的解决:
修改listener的inbound_connect_timeout参数的方法
方法一:
[bglbj1][oracle][/home/oracle]>lsnrctl
LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 01-SEP-2009 16:28:06
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Welcome to LSNRCTL, type "help" for information.
LSNRCTL> help
The following operations are available
An asterisk (*) denotes a modifier or extended command:
start              stop               status            
services           version            reload            
save_config        trace              spawn             
change_password    quit               exit              
set*               show*             
LSNRCTL> show
The following operations are available after show
An asterisk (*) denotes a modifier or extended command:
rawmode                    displaymode               
rules                      trc_file                  
trc_directory              trc_level                 
log_file                   log_directory             
log_status                 current_listener          
inbound_connect_timeout    startup_waittime          
snmp_visible               save_config_on_stop       
dynamic_registration      
LSNRCTL> set
The following operations are available after set
An asterisk (*) denotes a modifier or extended command:
password                   rawmode                   
displaymode                trc_file                  
trc_directory              trc_level                 
log_file                   log_directory             
log_status                 current_listener          
inbound_connect_timeout    startup_waittime          
save_config_on_stop        dynamic_registration      
LSNRCTL>
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> set inbound_connect_timeout 0 #禁止
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER parameter "inbound_connect_timeout" set to 0
The command completed successfully

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

LSNRCTL> set save_config_on_stop on  #表示修改参数永久生效,否则只是临时生效,下次重启监听又还原为原来的值了
LSNRCTL> exit

方法二:等于0代表取消这个功能。
1)编辑服务端的sqlnet.ora文件,添加这个参数:
SQLNET.INBOUND_CONNECT_TIMEOUT=<n>
<n>代表秒。
例如:
SQLNET.INBOUND_CONNECT_TIMEOUT = 120
2)编辑listener.ora文件,添加这个参数:
INBOUND_CONNECT_TIMEOUT_<listenername> = <n>
<n>代表超时的秒。
问题解决
修改后依然是启动不了数据库,但在依然启动不了数据库连sqlplus环境都进不去,我查看来最新一个udump 下的
trc文件,其中有Dumping diagnostic information for LCK0:
OS pid = 422264
loadavg : 0.23 0.25 0.26
swap info: free_mem = 17.67M rsv = 128.00M
           alloc = 12067.13M avail = 32768.00M swap_free = 20700.87M
       F S      UID    PID   PPID   C PRI NI ADDR    SZ    WCHAN    STIME    TTY  TIME CMD
  240001 A   oracle 422264      1   0  60 20 a0b36400 106964            Feb 10      -  1:47 ora_lck0_rzywk2
open: The file access permissions do not allow the specified action.
Warning: executed in non-root mode
procstack cannot verify that /unix matches the running kernel.
Kernel symbols might not be validated.
422264: ora_lck0_rzywk2
0x00000001000fc898  sskgpwwait(??, ??, ??, ??, ??) + 0x38
0x00000001000f9e7c  skgpwwait(??, ??, ??, ??, ??) + 0xbc
0x000000010011e42c  kslges(??, ??, ??, ??, ??) + 0x54c
0x000000010012225c  kslgetl(??, ??, ??, ??) + 0x33c
0x00000001049f0998  ksfglt(??, ??, ??, ??, ??) + 0x198
0x00000001045d1b84  kqlmbfre() + 0x144
0x00000001045d61c4  kqlmba(??, ??) + 0x24
0x000000010015efa8  ksbcti(??, ??, ??) + 0x3c8
0x0000000100169f1c  ksbabs(??) + 0x3fc
0x00000001019b5e18  kclabs(??) + 0xd8
0x0000000100166dd4  ksbrdp() + 0x4b4
0x000000010430c93c  opirip(??, ??, ??) + 0x3fc
0x0000000102d9ae38  opidrv(??, ??, ??) + 0x458
0x000000010370b950  sou2o(??, ??, ??, ??) + 0x90
0x0000000100000870  opimai_real(??, ??) + 0x150
0x00000001000006d8  main(??, ??) + 0x98
0x0000000100000368  __start() + 0x98
*** 2011-02-12 05:20:09.050
*** 2011-02-12 05:20:19.051
Waited for detached process: LCK0 for 310 seconds:
*** 2011-02-12 05:20:19.051
Dumping diagnostic information for LCK0:
OS pid = 422264
loadavg : 0.36 0.27 0.27
swap info: free_mem = 32.64M rsv = 128.00M
           alloc = 12072.14M avail = 32768.00M swap_free = 20695.86M
       F S      UID    PID   PPID   C PRI NI ADDR    SZ    WCHAN    STIME    TTY  TIME CMD
  240001 A   oracle 422264      1   0  60 20 a0b36400 106964            Feb 10      -  1:47 ora_lck0_rzywk2
open: The file access permissions do not allow the specified action.
Warning: executed in non-root mode
procstack cannot verify that /unix matches the running kernel.
Kernel symbols might not be validated.
 
依据此处和alterSID.log的内容:
ksvcreate: Process(m000) creation failed
Sat Feb 12 05:19:14 2011
Errors in file /oracle/app/oracle/admin/rzywk/bdump/rzywk2_j002_512250.trc:
ORA-12012: error on auto execute of job 42791
ORA-27468: "EXFSYS.RLM$EVTCLEANUP" is locked by another process
Sat Feb 12 05:40:42 2011
Errors in file /oracle/app/oracle/admin/rzywk/bdump/rzywk2_j002_614620.trc:
ORA-12012: error on auto execute of job 42792
ORA-27468: "EXFSYS.RLM$SCHDNEGACTION" is locked by another process
Sat Feb 12 05:45:05 2011
Errors in file /oracle/app/oracle/admin/rzywk/bdump/rzywk2_j003_516258.trc:
ORA-12012: error on auto execute of job 42791
ORA-27468: "EXFSYS.RLM$EVTCLEANUP" is locked by another process
Sat Feb 12 05:55:20 2011
kkjcre1p: unable to spawn jobq slave process
Sat Feb 12 05:55:20 2011
Errors in file /oracle/app/oracle/admin/rzywk/bdump/rzywk2_cjq0_434552.trc:
Sat Feb 12 05:57:36 2011
kkjcre1p: unable to spawn jobq slave process
Sat Feb 12 05:57:36 2011
Errors in file /oracle/app/oracle/admin/rzywk/bdump/rzywk2_cjq0_434552.trc:
可以判断是oracle内部的进程锁定的,上面的内容说的很清楚,就是422264      这个进程编号,
kill -9 422264 再进入sqlplus  "/as sysdba"  可以登录了,startup 数据库成功启动。
附上解决此问题的其他方案和分析:
 
总结:
在排查问题的时候,需要借助告警日志和trc 11g数据库默认都是在这个目录:$ORACLE_BASE/diag/rdbms/orcl/orcl/trace
1.查看 user_dump_dest参数,就可以知道当前系统的trace文件的位置
SQL> show parameter user_dump_dest

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
user_dump_dest string /u01/app/oracle/diag/rdbms/cbl
/cbl1/trace
2.查看是否开启了生成追踪sql的trace文件,但这不影响生成数据库进程的trace文件
show parameter sql_trace
Name          Type        Value
-------------------------------------------
sql_trace     boolean      false
如果value是false表示系统当前不会产生追踪sql的trace文件,但是依旧会产生一些数据库进程的trace文件(前提是该进程有警告或者有错误),
.采取如下操作让系统产生追踪sql的trace文件:注意一般情况是不开启的,因为消耗性能。
alter session set sql_trace=true;
或者:alter system set sql_trace=true;
启动sql trace 之后收集的信息包括
1.解析、执行、返回数据的次数
2.cpu和执行命令的时间
3.物理读和逻辑读的次数
4.系统处理的记录数
5.库缓冲区错误
sql trace 的输出结果:
count:提供OCI过程的执行次数
CPU: 提供执行CPU所花的时间单位是秒
Elapsed:提供了执行时所花的时间。单位是秒。这个参数值等于用户响应时间
Disk:提供缓存区从磁盘读取的次数
Query:以一致性模式从缓存区获得数据的次数
Current:以当前模式从缓存区获得数据的次数
ROWs: 返回调用或执行调用时,处理的数据行的数量。
[oracle@S249 oracle]$ cd $ORACLE_BASE/diag/rdbms/orcl/orcl/trace
[oracle@S249 trace]$ ll -rt #按时间排序
然后有针对性的去查看,trace文件,貌似是一个进程对应一个trace文件
[oracle@S249 trace]$ more orcl_dbrm_26863.trc
可以使用oracle自带工具 tkprof来格式化输出trace文件。
使用tkprof生成相关文件,tkprof放在$ORACLE_HOME/bin目录下,如无法执行请检查环境变量和PATH
[oracle@S249 oracle]$ tkprof erptest_ora_27576.trc session.txt explain=system/manager aggregate=yes sys=no waits=yes sort=fchela
相关说明:
sys=no:表示阻止所有以sys用户执行的sql被显示出来,默认为YES
aggregate=yes|no 若用户指定AGGREGATE=NO,TKPROF将不会对相同SQL文本的多个用户进行汇总
waits=yes|no Record summary for any wait events found in the trace file.
CALL: 每次SQL语句的处理都分成三个部分(Parse,Execute,Fetch)
Parse: 这步将SQL语句转换成执行计划,包括检查是否有正确的授权和所需要用到的表、列以及其他引用到的对象是否存在。
Execute: 这步是真正的由Oracle来执行语句。对于insert、update、delete操作,这步会修改数据,对于select操作,这步就只是确定选择的记录。
Fetch: 返回查询语句中所获得的记录,这步只有select语句会被执行。
COUNT: 这个语句被parse、execute、fetch的次数。
CPU: 这个语句对于所有的parse、execute、fetch所消耗的cpu的时间,以秒为单位。
ELAPSED: 这个语句所有消耗在parse、execute、fetch的总的时间。
DISK: 从磁盘上的数据文件中物理读取的块的数量。一般来说更想知道的是正在从缓存中读取的数据而不是从磁盘上读取的数据。
QUERY: 在一致性读模式下,所有parse、execute、fetch所获得的buffer的数量。 一致性模式的buffer是用于给一个长时间运行的事务提供一个一致性读的快照,缓存实际上在头部存储了状态。
CURRENT: 在current模式下所获得的buffer的数量。一般在current模式下执行insert、update、delete操作都会获取buffer。在current模式下如果在高速缓存区发现有新的缓存足够给当前的事务使用,则这些buffer都会被读入了缓存区中。
ROWS: 所有SQL语句返回的记录数目,但是不包括子查询中返回的记录数目。对于select语句,返回记录是在fetch这步

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29654823/viewspace-2138845/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/29654823/viewspace-2138845/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值