日归档：2014 年 10 月 8 日

因此，下面我尝试比这个方法稍微科学一点点的方法2：重新执行节点1的root.sh，来尝试修复节点1的权限问题。 使用rootcrs.pl -deconfig删除crs配置信息： 使用root.sh重新配置crs： 配置结束后，可以看到，节点1的数据库是不能正常启动的： 这个原因是很明显的，跟手工修改u01目录权限一文中的类似： 修改oracle二进制文件的权限： 再次尝试启动数据库： 再回过头看看root.sh修改了哪些主要目录的权限： 这些目录是11.2 RAC的基本服务资源。从11.2开始，GI中不再显示类似上面的基础服务资源，需要使用init参数来看： 从修改过程可以看出，感觉上，root.sh比第一种手工修改的方法科学一点，但是居然oracle二进制文件的权限还是没有修改好，那么其他的是否有细节问题，不好说。 总之，Oracle建议的方法，还是加减节点，让Oracle完全的重构这个节点的所有文件，以防止日后任何的CRS异常终止或者异常宕机等行为。

还原节点损坏的场景： 可以看到，此时crs起不来了，后台报错： 可以看到，卡在ora.mdnsd服务不能启动： 使用rootcrs.pl的init选项尝试修复，结果是不行的： 后台日志的报错信息，跟上面的是雷同的。 可见，使用rootcrs.pl -init修复目录权限，在chown -R /u01面前，作用不大。

正如在11.2 RAC 上所有grid环境需要的文件的权限配置文件：crsconfig_fileperms 和 11.2 RAC 上所有grid环境需要的目录的权限配置文件：crsconfig_dirs中描述的，理论上，根据这两个文件，自己写一个shell脚本修改全部grid环境所需的权限，看上去是可以的。 也正如11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法-1-手工修复错误的权限中所证明的，其实真要是手工修改，只为了让crs可以起来，完全不必要那么麻烦，只要简单的几条命令即可，但是上面的3种手工修改权限的方法，都是oracle官方所不支持的，以前也有人log SR专门问过这类问题，官方给的推荐方法就是remove nodes and add nodes： 这种解释是很好理解的，11.2 RAC相对10.2来说可以说是重新设计的，相对复杂很多的庞然大物，其附带的功能也非常多，因此，手工修改后，到底会有什么风险，稳定性如何保证都是问题…… 因此，明天我用加减节点的方法来重现故障后，再减节点和加节点的方法修复试试看，O(∩_∩)O哈哈~

在11.2RAC中，如果修改了gird的安装目录(类似chown -R xxx /u01)，比如通常我们会使用/u01，则crs会出现不能启动的状态，启动时，mdnsd进程会首先卡主，crs日志会有如下信息： 下面我们尝试使用3种方法来修复该问题。 方法1————直接修改/u01和其他相关文件或者目录的权限： 注意： 此方法，仅仅用于紧急启动数据库或者ASM的不得已的做法，在生产环境下，官方建议的做法是删除节点和添加节点（后面会在方法3中详细描述）。 首先修改/u01目录为grid:oinstall，并修改/u01/app/oracle为oracle:oinstall 如果进行上述目录权限的修改，那么crs表面可以启动，但是可以看到后台重要的agent进程都是错误的状态： 还有一些对ohasd和crsd比较关键的文件的权限，也一并修改了： 此时启动可以crs可以启动了。 但是，可以看到目录权限有问题的节点，数据库没有正常启动： 手工启动数据库，报错信息如下： 这个错误通常意味着oracle二进制文件权限不对，尝试修改： 正常情况下，$GRID_HOME/bin/oracle和$ORACLE_HOME/bin/oracle的权限都应该是6751，即“-rwsr-s–x” 对比下节点2（正常节点）： 再看看节点1（问题节点）： 手工修改$GRID_HOME/bin/oracle文件权限： 顺便检查一下$ORACLE_HOME/bin/oracle文件权限： 现在，再重新启动数据库： 目前该数据库貌似可以启动了，如果在很多异常情况下，目前的情况，已经可以尝试导出数据库或者备份数据库等等了。 但是这种状态的crs和数据库是存在很大隐患的，比如很可能会异常宕机或者出现其他莫名其妙的损坏等情况。 因此，一旦权限出现问题，要么使用rootcrs.pl -init修复（通常这种情况下，这种修复是徒劳的，后面的测试会证明这一点） 否则官方不支持任何手工手工修改权限的做法。就这一点，官方有明确的: