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

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_<listener_name>=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^_^

遭遇Oracle11g第一个bug

昨晚安装软件,dbca建库,一切顺利。弄完后就睡觉了,谁知道今天一开机,输入sqlplus,晕,报错了,sqlplus无法打开:

sqlplus: error while loading shared libraries:/oracle/11g/lib/libnnz11.so:

cannot restore segment prot after reloc: Permission denied

Google了一下,oracle论坛里有人提到metalink 454196.1,晕,遭遇bug了,还是个未正式发布的bug:Bug 6140224, “SQLPLUS FAILS TO LOAD LIBNNZ11.SO WITH SELINUX ENABLED ON EL5/RHEL5″ 。这个问题只影响到RadHat Enterprise Linux 5,说是其SELinux的模式默认为“Enforcing”,改成“Permissive”模式能暂时解决该问题。

以root身份,通过以下命令查询SELinux的模式:getenforce 默认应当返回Enforcing
通过以下命令更改模式:setenforce 0
然后再次查询getenforce,应该返回permissive了

以上修改在系统重启前有效,重启后系统又会变回默认的enforcing模式。如果需要启动即为permissive模式,则需要在grub的启动项中增加enforcing=0,例如

title Red Hat Enterprise Linux ES (2.6.18-8.EL)
root (hd0,0)
kernel /vmlinuz-2.6.18-8.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet enforcing=0
initrd /initrd-2.6.18-8.EL.img

另外,也可以通过setupfirewall configuration来设置SELinux的模式。

SQL> select * from v$version;
 
BANNER
------------------------------------------------------------------
--
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

PL/SQL Release 11.1.0.6.0 - Production
CORE    11.1.0.6.0      Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production