重要的信息已用红色字体标出，大致的意思是，oracle用户下的agent进程无法启动导致ora.shpboss.db 这个DB资源无法启动，我们知道正常情况下srvctl 启动数据库时会同时在oracle用户启动一个名为oraagent_bin的agent进程，就像下面那样
root@qzp750707b:/home/grid>ps -ef|grep oraagent
grid 15663174 1 0 14:28:38 - 0:01 /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent.bin
oracle 10944808 1 0 14:28:44 - 0:03 /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent.bin
grid 20578696 1 0 14:27:32 - 0:00 /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent.bin
但事发当时却找不到oracle用户下的这个agent进程，只有grid用户下的两个。
$GRID_HOME下的安装目录及文件权限比DB要复杂的多，常见的有两种属主：root:oinstall和grid:oinstall，找了另一个11.2.0.4的RAC环境作为参照，$GRID_HOME目录下应该有以下一些目录的属主是root:oinstall的：
grid@qc740701a:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt | awk '$3~/root/'
drwxr-xr-x 17 root oinstall 4096 Jul 31 2014 crs
drwxr-x--- 3 root oinstall 256 Jul 31 2014 gnsd
drwxr-xr-x 3 root oinstall 256 Jul 31 2014 osysmond
drwxr-xr-x 3 root oinstall 256 Jul 31 2014 ologgerd
drwxr-xr-x 3 root oinstall 256 Jul 31 2014 ctss
drwxr-x--- 4 root oinstall 256 Jul 31 2014 crf
drwxrwxrwt 6 root oinstall 256 Jul 31 2014 auth
drwxr-xr-x 3 root oinstall 12288 Jul 31 2014 lib
drwxr-xr-x 2 root oinstall 16384 Jul 31 2014 bin
drwxr-xr-x 4 root system 256 Jul 31 2014 tfa
而如今这些目录都清一色刷成了grid.oinstall，以下命令自然就没有输出了
root@qzp750707b:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt | awk '$3=root'
srvctl 命令启动db时无法吊起的agent进程对应的可执行文件oraagent.bin正是位于$GRID_HOME/bin目录下，这样的诡异报错不免驱动我先去解决权限，先把错误的权限改对了再说。如果仅是手动改这些目录的属主还能接受，也就十来个，关键是目录下还有子目录和文件，这些子目录和文件的属主也root.oinstall的，手工逐个修改肯定不现实，难道要重装GI？ 多番查找终于找到一个较为省力且可靠的方法：
在PSU >=11.2.0.3.6的版本下可以通过root用户执行<GRID_HOME>/crs/install/rootcrs.pl -init来恢复GRID_HOME目录下部分权限被篡改的文件或者目录的权限（为什么仅是部分，不是全部后面再解释），这条命令执行用时很快，不到5秒钟就返回命令行提示符了
root@qzp750707b:/home/grid>/oracle/app/grid/product/11.2.0/grid_1/crs/install/rootcrs.pl -init
Using configuration parameter file: /oracle/app/grid/product/11.2.0/grid_1/crs/install/crsconfig_params <---这个配置文件是在安装GI时生成的，用来帮助rootcrs.pl寻找GRID_HOME路径
root@qzp750707b:/home/grid>
查看一下效果，的确都改过来了
root@qzp750707b:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt | awk '$3~/root/'
drwxr-xr-x 17 root oinstall 4096 Feb 23 19:29 crs
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 osysmond
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 ologgerd
drwxr-x--- 3 root oinstall 256 Feb 23 19:29 gnsd
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 ctss
drwxr-x--- 4 root oinstall 256 Feb 23 19:29 crf
drwxr-xr-x 3 root oinstall 12288 Feb 23 19:29 lib
drwxr-xr-x 2 root oinstall 16384 Feb 23 19:31 bin
在另一个节点如法炮制，终于srvctl 能够正常启动了db了，这还不放心，在两个节点上都执行了一边crsctl stop crs->crsctl start crs，对GI做一次完整的停启操作，该启的资源都能起来，GI和DB的alert.log里都没有报错，悬着的心这才放下。