一个客户的STANDBY数据库出现了ORA-494的错误。
数据库服务器建立在IBM的POWER 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都跑满，也不可能使得操作系统完全不可登录，更不要说这只是一个应用日志的备库而已。而且就算是Oracle的bug，对于单实例配置的数据库，能把服务器一起挂掉的情况还真不多见（Windows服务器除外）。
下面就是检查操作系统的信息，确认这个问题和Oracle没有关系，而Oracle所报的ORA-494错误，仅仅是由于缺少资源或者操作系统不正常所致。
可惜的是errpt中看不到任何有价值的错误信息。不过好在系统中部署了nmon，可以看到出现问题这一天系统的运行状况。nmon正常采样数据截至到19:05，从19:05到20:25之间数据丢失，20:25是最后一条采样数据。
除了nmon信息不完整外，还找到两个疑点：一个是CPU的sys利用率很高，在HANG住之前，有两个小时左右sys占用了整个cpu的40%，而几乎看不到任何的user和wait；二是从上午数据库重启之后，可用内存阶梯状下降，空闲内存从70G一直下降到问题前1、2个小时的100M左右。其中占用内存空间主要是FSCache，它的贡献大约在整个内存的70%左右。
操作系统工程师通过vmo –F –a检查参数，排除了内存方面的问题。可用内存降到接近0是与AIX上内存使用规则和参数设置有关，这种配置下AIX上内存会优先使用空闲内存，只有空闲内存剩余小于参数设置的阈值后，AIX才会尝试在FSCache中获取内存。
而CPU中的sys一直无法解释，因此也被认为是导致问题的原因。而且在检查各个CPU的使用情况时，发现另一个比较奇怪的现象，CPU的使用基本上分为两个极端，在问题发生时刻，一部分CPU完全空闲，一部分CPU的SYS跑到100%。
问题最后由一个IBM原厂的高级工程师定位，在P7系列服务器中如果在分区之间动态划分CPU和内存资源，而没有重启主机的话，是可能导致部分CPU工作不正常的，这个问题他们曾经在其他系统中碰到过，且目前已经提交到IBM实验室进行解决。而这个系统确实在前一天进行过动态划分CPU和内存的操作，且没有进行重启操作系统。现场尝试重现问题时发现，动态划分一部分CPU再动态收回后，CPU的序号确实出现错乱，因此证明了bug的存在。
这个问题基本确定，由于大量的资源划分到当前分区中并没有完全正常的发挥作用，而操作系统和Oracle都是安装资源划分后的CPU和内存来管理和使用资源，最终导致系统出现问题，部分可用cpu sys上升到100%，而更多不可用的cpu负载为0，整个系统HANG住。
短期内解决这个问题的方法就是在LPAR划分资源后重新启动系统，这时系统就可以正常的使用划分后的资源了。