RAC节点启动失败--ASM无法连接

近日遇到一个RAC问题，一个节点无法启动，经过分析后解决，解决过程如下。11.2.0.3RAC环境，其中一个节点instance启动失败，显示如下错误[oracle@exadbmel04~]$c

近日遇到一个RAC问题，一个节点无法启动，经过分析后解决，解决过程如下。

 通过Sqlplus启动，遇到同样的错误

 查看资源，可以看到ASM的实例都是正常的，包括diskgroup，但是实例exadbmel04未启动。

通过查询ORA-27300错误，找到问题点。

这个问题是这个文件 $GI_HOME/bin/oracle 的权限不对，正确的权限应该是 "-rwsr-s--x".将权限修改正确，问题解决。

启动实例，香港服务器，正常启动

 使用sqlplus验证，数据库已经可以正常访问

 

遇到这种问题的可能，

1、是人为修改该文件的权限，

2、还有就是apply patch失败，apply patch的过程会有修改该文件权限为-rwxr-xr-x的动作，在apply patch完成后再修改回来，但是如果apply patch失败，就会导致该文件权限一直是错误的状态，需要手动修改回来。

    最后分析 $GI_HOME/bin/oracle文件权限中的“S”，这个权限问题明白了，oracle的这个问题也就解释了。查询Linux权限，美国服务器，得到这样的解释

Linux 权限模型有两个专门的位，香港空间，叫做“suid”和“sgid”。当设置了一个可执行程序
的“suid”这一位时，它将代表可执行文件的所有者运行，而不是代表启动程序的人运行。
现在，回到可执行文件，我们可以
看到它属于 root 用户：

。这表明，对于这个特殊程序，
设置了用户执行（
具有完全超级用户访问权），而不是代表运行它的用户运行。又因为用户访
问权运行，所以能够修改 /etc/passwd 文件，而没有什么问题。

suid/sgid 告诫说明

我们看到了 suid 怎样工作，sgid 以同样的方式工作。它允许程序继承程序的组所有权，而不
是当前用户的程序所有权。

引用ITPUB的一个帖子，其中有相关问题及解析

?mod=viewthread&tid=1622940

这里面说的问题原因就是 $ORACLE_HOME/bin/oracle 和  $GI_HOME/bin/oracle下的oracle程序的权限都是这样设置的，并且他们的属组是不同的，所以在实际操作的连接过程中，需要相互调用对方oracle程序，来申请SGA内存区

可以看到下面各自的属组是不同的，如果需要使用对方的应用程序并且使用该应用程序的属组，那么，唯一的办法是使用"S"权限。

 

本文出自 “小小狗窝” 博客，谢绝转载！