资源耗尽导致ORA-494错误

一个客户的STANDBY数据库出现了ORA-494的错误。

 

 

数据库服务器建立在IBMPOWER 7利用LPAR划分的逻辑分区上,目前上面只有一个备库在跑日志应用,前一天利用LPAR向这个分区又添加了CPU和内存资源,使得当前的CPU数从32增加到96,内存从48G增加到98G

如此强劲的硬件配置,却出现了系统HANG的问题。而当天除了物理STANDBY数据库的正常日志应用外,只不过进行了一次操作系统级的备份。

对应的数据库的高级日志信息为:

Thu Oct 13 19:03:55 2011
Media Recovery Log /archlog/1_133940_665275242.dbf
Thu Oct 13 19:04:17 2011
Media Recovery Log /archlog/1_133941_665275242.dbf
Media Recovery Waiting for thread 1 sequence 133942 (in transit)
Thu Oct 13 19:21:33 2011
Errors in file /oracle/admin/db1/bdump/db1_arc0_3408616.trc:
ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 25886816'
Thu Oct 13 22:48:41 2011
Errors in file /oracle/admin/db1/udump/db1_rfs_21496166.trc:
ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 8454874'

刚开始听到这个错误时以为是一个普通的BUG,随着对问题的深入了解,我的观点也发生了改变。最重要的一个理由是操作系统也一同HANG住了,以致于最终不得不通过重启系统来解决这个问题。

事实上,到现场之前我还特意留意了一下METALINK中有哪些ORA-494错误和DATA GUARD配置有关,而在现场了解了情况之后,我再没有查询过METALINK。很显然问题已经不是Oracle数据库层面上的了,即使Oracle性能再差,把所有CPU都跑满,也不可能使得操作系统完全不可登录,更不要说这只是一个应用日志的备库而已。而且就算是Oraclebug,对于单实例配置的数据库,能把服务器一起挂掉的情况还真不多见(Windows服务器除外)。

下面就是检查操作系统的信息,确认这个问题和Oracle没有关系,而Oracle所报的ORA-494错误,仅仅是由于缺少资源或者操作系统不正常所致。

可惜的是errpt中看不到任何有价值的错误信息。不过好在系统中部署了nmon,可以看到出现问题这一天系统的运行状况。nmon正常采样数据截至到19:05,从19:0520:25之间数据丢失,20:25是最后一条采样数据。

除了nmon信息不完整外,还找到两个疑点:一个是CPUsys利用率很高,在HANG住之前,有两个小时左右sys占用了整个cpu40%,而几乎看不到任何的userwait;二是从上午数据库重启之后,可用内存阶梯状下降,空闲内存从70G一直下降到问题前12个小时的100M左右。其中占用内存空间主要是FSCache,它的贡献大约在整个内存的70%左右。

操作系统工程师通过vmo –F –a检查参数,排除了内存方面的问题。可用内存降到接近0是与AIX上内存使用规则和参数设置有关,这种配置下AIX上内存会优先使用空闲内存,只有空闲内存剩余小于参数设置的阈值后,AIX才会尝试在FSCache中获取内存。

CPU中的sys一直无法解释,因此也被认为是导致问题的原因。而且在检查各个CPU的使用情况时,发现另一个比较奇怪的现象,CPU的使用基本上分为两个极端,在问题发生时刻,一部分CPU完全空闲,一部分CPUSYS跑到100%

问题最后由一个IBM原厂的高级工程师定位,在P7系列服务器中如果在分区之间动态划分CPU和内存资源,而没有重启主机的话,是可能导致部分CPU工作不正常的,这个问题他们曾经在其他系统中碰到过,且目前已经提交到IBM实验室进行解决。而这个系统确实在前一天进行过动态划分CPU和内存的操作,且没有进行重启操作系统。现场尝试重现问题时发现,动态划分一部分CPU再动态收回后,CPU的序号确实出现错乱,因此证明了bug的存在。

这个问题基本确定,由于大量的资源划分到当前分区中并没有完全正常的发挥作用,而操作系统和Oracle都是安装资源划分后的CPU和内存来管理和使用资源,最终导致系统出现问题,部分可用cpu sys上升到100%,而更多不可用的cpu负载为0,整个系统HANG住。

短期内解决这个问题的方法就是在LPAR划分资源后重新启动系统,这时系统就可以正常的使用划分后的资源了。

 

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

转载于:http://blog.itpub.net/4227/viewspace-713463/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值