连续两台全新安装的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啊，总是来了又走，走了又来，就像移动联通电信，分了又合，合了又分，呵呵。
Oracle10g的问题还真多，一个接一个。之所以标题说这个是问题而不是bug，是因为metalink说这是10g功能的增强而不是bug。
在做主备切换的时候，需要将备库的联机日志文件清除(clear online redo logfile)，为了加快switchover的速度，Oracle10g在将备库置于manged standby状态的时候就提前将这个clear的动作做了，这个想法是好的，只是实现有点糟糕，会在alert里记录错误一堆错误：
Errors in file /u01/oracle/admin/ning/bdump/ning_mrp0_319584.trc:
ORA-00367: checksum error in log file header
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: ‘/u01/oracle/oradata/ning/redo01_01.dbf’
Clearing online redo logfile 1 /u01/oracle/oradata/ning/redo01_01.dbf
Clearing online log 1 of thread 1 sequence number 3715
Tue Mar 4 19:00:07 2008
Errors in file /u01/oracle/admin/ning/bdump/ning_mrp0_319584.trc:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: ‘/u01/oracle/oradata/ning/redo01_01.dbf’
Clearing online redo logfile 1 complete
Oracle不承认这是bug，不过还是给出了解决方法：首先要在备库创建online redo logfile，然后设置log_file_name_convert参数，即使主备库日志文件的路径和名字都一样也要设置，不然还是会报ORA-19527。
参考Note:352879.1
10g的备库刚上没两天，发现alert里报MMON process无法创建：
Tue Mar 4 15:37:59 2008
ksvcreate: Process(m000) creation failed
Tue Mar 4 15:38:59 2008
ksvcreate: Process(m000) creation failed
Tue Mar 4 15:40:02 2008
Metalink一查，恭喜又是Bug 5583049，在将备库read only打开然后回到恢复状态再open read only，反复多次的时候可能触发，还真是绕啊。这个bug没有patch，据说在11g解决。临时方案一：重启实例；临时方案二：关闭ADDM。参考Note:418553.1
下午同时做两个备库，一个9206，一个10203的，都是通过NFS直接将主库的RMAN备份挂到备库相同路径。然后通过rman来restore。
9206的一切正常，10203报错：
ORA-19870: error reading backup piece /bak/rmanbak/test/0ija94hs_1_1_18.bak
ORA-19505: failed to identify file “/bak/rmanbak/test/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′
Recent Comments