遭遇Oracle11gR2 ASM文件无法扩展的Bug

在一个11gR2+ASM的环境中,因为产生了大量归档,导致控制文件需要扩展,结果数据库报错:

Errors in file /opt/oracle/diag/rdbms/test/test/trace/test_arc0_11146.trc:
ORA-00202: control file: '+DATA/control01.ctl'
ORA-17505: ksfdrsz:1 Failed to resize file to size 1920 blocks
ORA-15061: ASM operation not supported [41]
Control file expansion from 1600 blocks to 1920 blocks denied by OS

这是ASM的一个bug 8898852,可以在Oracle Support上找到对应的小patch,经过验证可以解决该问题。该patch已经包含在前两天刚发布的ASM的PSU中,只需要安装该PSU即可。

从目前我们使用11gR2的一些经验来看,bug还是比较多,尤其是一些影响比较大的bug,还是让人对11gR2无法完全放心,只能在特定的环境,和有足够容错方案的环境中,才能冒着风险来试用。

除了这个ASM文件不能扩展,有几个从10.2.0.4升级到11.2.0.1的库,在switchover中碰到了两次ORA-600 [ktbdchk1: bad dscn],出现问题后无法执行DML,非常严重的一个问题,并且暂时还没有好的办法解决,只能通过重建有问题的表的方式绕过,因为两次都是在切换后出现,初步推断是Active Data Guard带来的bug,开了SR和Oracle扯了很久,还在继续研究中。

据说Oracle 11.2.0.2将在年中发布,希望这个新的版本能更稳定些吧。

4月份,Oracle11.2.0.1的PSU和ASM(Grid Infrastructure)的第一个PSU都已经发布了,如果需要在产品环境中使用,建议这些PSU都打上吧

Oracle Database PSU Unix Patch Comments

11.2.0.1.1

Patch 9352237

11.2.0.1.1 for GI

Patch 9343627

11.1.0.7.3

Patch 9352179

11.1.0.7.2 for CRS

Patch 9207257

Released in January 2010

10.2.0.4.4

Patch 9352164

10.2.0.4.4 for CRS

Patch 9294403

注:该表格摘自My Oracle Support Note: 854428.1l

Oracle10.2.0.4 Linux64版本监听存在多个子进程

Update:还是被这个监听搞了一回,即使加了SUBSCRIBE_FOR_NODE_DOWN_EVENT_ =OFF。连续两天出现swap和load过高导致数据库无法提供服务,甚至OS都无法登陆。在ps后发现有两个监听进程,kill后系统恢复正常。按照Oracle的建议,删除了ONS的配置文件$ORACLE_HOME/opmn/conf/ons.config,暂时看起来正常了

连续两台全新安装的Linux64+Oracle10.2.0.4的环境,启动listener后,都出现了4个进程:

more /etc/issue
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
Kernel \r on an \m


ps -ef | grep tns
oracle 3244 1 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 3245 3244 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 3246 3245 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 3247 3245 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 5841 5504 0 10:12 pts/2 00:00:00 grep tns

之前一台Linux32位平台从9i升级上来的没有这个问题,一套Linux64平台从10.2.0.3升级上来的RAC也没有这个问题。在10.2.0.3之前,曾经有一个bug 4518443,listener可能产生一个或者多个子进程,最终导致监听hang住无法提供服务。这回到好,一启动直接就开4个进程。Oracle在10.2.0.3版中加入了4518443的patch,应该是屏蔽了某段代码,而看来到10.2.0.4他们认为这段问题代码找到了解决方法,又加了进来,结果在Linux64平台上问题更严重了,faint。

通过Bug 4518443提供的workaround可以暂时屏蔽该问题, 在listener.ora中加入:

SUBSCRIBE_FOR_NODE_DOWN_EVENT_ =OFF

按照metalink的说法,这个语句关闭了监听自动向ONS(Oracle Notification Services)注册,正是这个注册可能导致监听启动子进程。ONS是RAC中的一个组件,禁用该特性将导致RAC的FAN(Fast Application Notification)特性不可用。还好我这里两台都是单机,这么解决应该没什么问题。

Bug啊,总是来了又走,走了又来,就像移动联通电信,分了又合,合了又分,呵呵。

通过NFS执行RMAN恢复遭遇ORA-27054

下午同时做两个备库,一个9.2.0.6,一个10.2.0.3的,都是通过NFS直接将主库的RMAN备份挂到备库相同路径。然后通过rman来restore。

9206的一切正常,10203报错:

ORA-19870: error reading backup piece /bak/rmanbak/NinGoo/0ija94hs_1_1_18.bak
ORA-19505: failed to identify file “/bak/rmanbak/NinGoo/0ija94hs_1_1_18.bak”
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 6

Metalink上一查,又碰到bug了。10g的bug真的不是一般的多,随便做个什么操作都可能碰到,晕死。昨天晚上RAC又出了点小毛病,一个节点down掉后无法mount,在其他节点测试,发现控制文件和某些数据文件都无法读取,trace出来一直在做gc domain validation等待,估计由于节点异常宕掉导致某些资源锁无法释放了,没办法只有重启所有节点,而且由于控制文件无法读写,还只能shutdown abort,剩最后一个节点的时候shutdown immediate成功。

10gR2通过NFS执行rman备份恢复都可能碰到这个Bug 5146667,描述详见Note:424785.1,临时解决方法,可以修改nfs的mount参数(不同的平台参数可能不一样),或者设置10298事件,或者打相关patch。查了下patch好像只有Solaris平台的…

event=’10298 trace name context forever, level 32′

继续给鲜果抓Bug

具体页面来自这里,注意到订阅者统计信息:

共5人订阅,其中7人分享了该频道

鲜果bug

这个数据我已经观察三天了,一直有问题。按我的理解,订阅者应该要多过分享人数的吧,难道不订阅也可以分享?我没发现有这个功能啊,而且在其他blog的统计中都没有看到这个问题。那么这个统计出错,而且是个别现象,说明数据肯定不是直接来自数据库的,应该是来自搜索引擎或者前台cache。鲜果的搜索引擎看起来毛病还真不少,又贡献了一个bug^_^

无觅相关文章插件,快速提升流量