怎么样解决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命令应该会将所有的权限位全部保留才对。