ITPub博客

首页 > 数据库 > Oracle > ora-00494引起rac宕机的分析处理

ora-00494引起rac宕机的分析处理

原创 Oracle 作者:datapeng 时间:2014-03-07 11:52:01 0 删除 编辑

1、问题分析
    12月1日早上8:20,客户报障说数据库无法连接上,使用sqlplus连接也无法连上。我本人,通过远程工具连接上去,发现数据库好的,并且检查集群如下:
[oracle@myrac1 ~]$ crs_stat -t

长时间没有响应

[oracle@myrac1 cssd]$ ps -ef | grep pmon
oracle    3308 19190  0 11:41 pts/2    00:00:00 grep pmon
oracle   18254     1  0 09:35 ?        00:00:00 asm_pmon_+ASM1
oracle   18474     1  0 09:36 ?        00:00:00 ora_pmon_testdb1

但是进入数据库,发现根据不可用

[oracle@myrac1 ~]$ sqlplus "/as sysdba"

SQL*Plus: Release 10.2.0.5.0 - Production on Fri Mar 7 10:25:15 2014

Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP,
Data Mining Scoring Engine and Real Application Testing options

SQL> select status from v$instance;

一直无法响应。这种状态,说明数据库已经无法使用!

检查alert日志发现:
从6点24开始,系统出现报错
Attempt to get Control File Enqueue by LGWR pid=17130 (mode=X, type=0, timeout=9
00) is being blocked by inst=2, pid=11498
Please check inst 2's alert log for more information on the blocker including a
possible ORA-00494 and related incident logs

出现数据库ora-00494

[oracle@myrac1 cssd]$ oerr ora 494
00494, 00000, "enqueue%s held for too long%s by '%s'"
// *Cause:  The specified process did not release the enqueue within
//          the maximum allowed time.
// *Action: Reissue any commands that failed and contact Oracle Support
//          Services with the incident information.

从这种报障情况来看,是由于集群的第二个节点对控制文件进行了锁定,并且产生了阻塞超过了900秒。第一节点无法得到资源,主动查杀了后台进程!而在第二个节点,这段时间没有任何日志!接到报错后,第二节点可以ping通,但无法连接,到机房接上显示屏、键盘后,没任任何显示,说明系统已经挂死
在第一个节点,就出现要求instances离开
Waiting for instances to leave:

Waiting for instances to leave:

Waiting for instances to leave:

所以,最后的结论来看,应该是第二节点在系统挂死前,已经持有cf锁,而第一节点无法申请到,进而引起宕机。

最后,我们没有办法,只好重新启动第二个节点,对第一个节点进行强制关闭数据库

SQL> shutdown abort;


2、解决办法

    为避免因为某一个节点的原因,引数据库集群宕机,oracle官方解决方案
    CF eq超过900秒,会报ORA-00494,10.2.0.4对ORA-00494引进一种新的处理机制,当出现这个错误时,不管是不是后台进程,只要是阻塞的,都会kill掉。因为cf 锁的一直存在,lgwr因为需要申请cf锁会一直等待,此时active session中有越来越多的log file sync,当cf eq超过900s,报ORA-00494的时候,先kill了ckpt,然后 lgwr也被kill,ckpt也被 kill掉,再在 11:57:35 将lgwr也kill了。同时在11:57:35 时,实例也crash了。设置_kill_controlfile_enqueue_blocker=false参数,可以不kill掉任何进程。(对于CF eq超过900s也不会处理)。
    如果在init.ora中设置_kill_enqueue_blocker=1 ,可以阻止kill后台进程,但是仍旧kill非后台的进程。出现这种问题的原因应该去找,为什么CF EQ会超过900s
SQL> select ksppinm,ksppstvl,ksppstdf from x$ksppi a,x$ksppcv b where a.indx = b.indx and ksppinm='_kill_controlfile_enqueue_blocker';
 
KSPPINM                                   KSPPSTVL
----------------------------------------- ------
_kill_controlfile_enqueue_blocker         TRUE   

建议将这个值调整为false

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

请登录后发表评论 登录
全部评论

注册时间:2013-12-06

  • 博文量
    227
  • 访问量
    2553901