遭遇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 |
||
|
11.2.0.1.1 for GI |
||
|
11.1.0.7.3 |
||
|
11.1.0.7.2 for CRS |
Released in January 2010 |
|
|
10.2.0.4.4 |
||
|
10.2.0.4.4 for CRS |
注：该表格摘自My Oracle Support Note: 854428.1l
Oracle10.2.0.4 Linux64版本监听存在多个子进程
Update:还是被这个监听搞了一回，即使加了SUBSCRIBE_FOR_NODE_DOWN_EVENT_
连续两台全新安装的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_
按照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人分享了该频道
这个数据我已经观察三天了，一直有问题。按我的理解，订阅者应该要多过分享人数的吧，难道不订阅也可以分享？我没发现有这个功能啊，而且在其他blog的统计中都没有看到这个问题。那么这个统计出错，而且是个别现象，说明数据肯定不是直接来自数据库的，应该是来自搜索引擎或者前台cache。鲜果的搜索引擎看起来毛病还真不少，又贡献了一个bug^_^
