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们遇到问题尽量查看官方支持文档,不要随意在生产环境上执行并不明确的命令。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181204G0VZ0700?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券