怎么样解决oracle可执行文件s位导致的Cluster资源组无法正常启动的问题?

怎么样解决oracle可执行文件s位导致的Cluster资源组无法正常启动的问题?

今天在客户处升级Oracle数据库,8174->9205。
客户的环境是两台Sun Fire v880,SunOS 2.8 02.2版本,Sun Cluster 3.0作为HA。

由于操作系统的02.2版本过低,在安装Oracle9205 Patch之前,必须要先打操作系统的补叮
之前我自己曾经作过一次,但是由于没有打完所有的补丁,结果导致整个主机都无法正常启动。
所以这次是SUN的工程师过来操作,将整个操作系统全部打到最新的补叮

中间碰到了一些问题,不一一叙述了。

而最后这个问题郁闷了很长时间。

我的数据库升级过程应该属于正常操作,我并没有在两个节点上都单独地安装oracle9i的软件。
首先在A节点上安装Oracle9201,然后升级到9205,升级完毕以后,创建新的数据库。之后,将$ORACLE_BASE整个目录全部tar成一个文件,ftp到B节点上,然后在B节点展开。

升级完毕以后,在两个节点分别单独启动数据库都没有任何问题。

但是在添加新的资源组时,出现了validate failed错误,检查B节点的/var/adm/messege文件,发现报错信息是$ORACLE_HOME/bin/oracle可执行文件的s bit not set。

知道问题的原因,解决起来就比较简单了。
chmod u+s,g+s $ORACLE_HOME/bin/oracle

然后重新创建oracle数据库的资源组,OK。

不过这还是一个奇怪的问题,因为tar命令应该会将所有的权限位全部保留才对。