Oh my God！属主与权限，居然让集群说宕就宕！

前言

很多DBA都喜欢遇到问题直接百度，当然，不是说百度给出的方法不能解决问题，只是在生产环境遇到问题时，直接按照百度的方法做变更还是显得草率了些。本文中的问题本来只是权限问题，但如果你完全按照百度操作就可能带来更多的问题。总结一下就是，看似简单，其实有坑！希望用我们的分享，帮DBA们跨山，涉水，驶小船，行专业之技能，保数据之安稳！

1、问题表象

近期遇到这样一个case：某客户生产系统，AIX平台11.2.0.3 RAC数据库的一个节点CRS宕掉，且无法启动。现场人员检查后发现一个现象--$GRID_HOME下大量的文件权限被修改，都是属主由grid变为root，虽然不能确定是这个问题导致CRS宕，但该问题应被纠正。

2、问题分析和处理

据现场人员说，他根据网上文章（度娘）的指导，运行了$ORACLE_HOME/crs/install/rootcrs.pl，发现不是所有文件权限都恢复正常，后来又运行roothas.pl及root.sh（不清楚为什么要运行root.sh)，都没恢复，后者（root.sh）还运行失败了。

我们接手后，首先尝试启动集群，发现若干初始资源状态异常(crsctl stat res -t -init)

检测CRS状态

在crsd.log中，有类似如下信息

但grid用户的组并没有问题。另一个问题报错完全一致，但有部分类似

于是尝试先将$GRID_HOME/bin/oracle文件修改属主为grid，再次启动集群，发现资源都可以正常，但实例资源状态不准确，虽然实例已经启动，但状态仍为OFFLINE。从这个现象来看，至少可以说明修复权限的思路没问题，那么需要将剩余的文件属主都修复。虽然官方提供的脚本rootcrs.pl在本例中不好用，但官方还提供了一个校验文件权限的命令

cluvfycomp software -n all -verbose

使用该命令后的显示类似为：

命令运行后会明确提示哪些文件数据状态异常，根据文件列表将所有文件手工（可用脚本来做）修改为正确的权限，重新启动集群，一切恢复正常。

3、问题总结

这个问题看起来就是因为权限问题导致的集群无法启动，但从现场的处理过程可以看出过于随意，官方文档没有任何地方标明需要运行root.sh,一旦运行出现其他问题就很可能需要重新删除和添加节点，无形中给后续的处理带来麻烦，所以，建议DBA们遇到问题尽量查看官方支持文档，不要随意在生产环境上执行并不明确的命令。