前言
很多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们遇到问题尽量查看官方支持文档,不要随意在生产环境上执行并不明确的命令。
领取专属 10元无门槛券
私享最新 技术干货