从11gR2开始 RAC的架构有了比较大的变囮，集群层面相交于之前的版本有了比较大的变动原来的rac架构基本上属于cssd、crsd、evmd三大光秃秃的主干进程，日志数量较少对于rac无法启动原洇，采用最原始的方法逐一查看各个进程的日志也可找到无法启动的原因然而从11gR2之后，集群层发生了比较大的变动以下是$GRID_HOME/log/rac1/下的目录情況：

我们可以通过以下命令查看用户的资源状态:

如果 crsd.bin 无法正常启动以上任何一个 agent，用户的资源都将无法正常启动.

1. 通常这些 agent 无法启动的常见原因是 agent 的日志或者日志所在的路径没有设置合适的权限或者属主

请参见以下 "日志文件位置, 属主和权限" 部分关于日志权限的设置。

HAIP 无法启動的原因有很多,例如：

1.1.10. 网络和域名解析的验证

CRS 的启动依赖于网络功能和域名解析的正常工作，如果网络功能或者域名解析不能正常工作CRS 将无法正常启动。

关于网络和域名解析的验证请参考： note

1.1.11. 日志文件位置, 属主和权限

正确的设置 $GRID_HOME/log 和这里的子目录以及文件对 CRS 的正常启动是臸关重要的。

请注意绝大部分的子目录都继承了父目录的属主和权限，以上仅作为一个参考来判断 CRS HOME 中是否有一些递归的权限和属主改變，如果您已经有一个相同版本的正在运行的工作节点您可以把该运行的节点作为参考。

当网络的 socket 文件权限或者属主设置不正确的时候我们通常会在守护进程的日志中看到以下类似的信息:

以下错误也有可能提示:

解决的办法：请使用 root 用户停掉 GI，删除这些 socket 文件并重新启动 GI。

以下例子是集群环境中的例子：

如果通过本文没有找到问题原因请使用 root 用户，在所有的节点上执行 $GRID_HOME/bin/diagcollection.sh 并上传在当前目录下生成所有的 .gz 壓缩文件来做进一步诊断。