转载

11gR2 GI和DB安装目录权限属主被修改后的恢复方法

某位仁兄新装一套11gR2 RAC的过程中，在GI的安装配置阶段遇到了安装目录无法写入的报错，于是他便将$GRID_HOME下所有目录和文件属主改成了grid:oinstall，将$GRID_HOME下所有目录和文件权限改成了757，将$ORACLE_HOME下所有的目录和文件权限改成了757，侥幸过了安装这一关，紧接着麻烦就找上门了：使用srvctl无法启动数据库，症状如下：

$ /oracle/app/oracle/product/11.2.0/db_1/bin/srvctl start database -d shpboss -o open

PRCR-1079 : Failed to start resource ora.shpboss.db

CRS-2503: Resource 'ora.shpboss.db' is in UNKNOWN state and must be stopped first

CRS-2680: Clean of 'ora.shpboss.db' on 'qzp750707b' failed

CRS-5802: Unable to start the agent process <--- 关键在于oracle agent无法启动

---GI的alert.log：$GRID_HOME/log/qzp750707b/alertqzp750707b.log里显示

2016-03-02 12:33:01.991:

[crsd(9109618)]CRS-5828:Could not start agent '/oracle/app/grid/product/11.2.0/grid_1/bin/oraagent_oracle'. Details at (:CRSAGF00130:) {1:54418:222} in /oracle/app/grid/product/11.2.0/grid_1/log/qzp750707b/crsd/crsd.log.

---crsd.log里的日志就有点眼花缭乱了

2016-03-02 12:33:01.992: [ CRSD][10539]{1:54418:222} {1:54418:222} Created alert : (:CRSAGF00130:) : Failed to start the agent /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent_oracle

2016-03-02 12:33:01.992: [ AGFW][10539]{1:54418:222} Agfw Proxy Server sending the last reply to PE for message:RESOURCE_START[ora.shpboss.db 1 1] ID 4098:797

2016-03-02 12:33:01.992: [ AGFW][10539]{1:54418:222} Can not stop the agent: /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent_oracle because pid is not initialized

2016-03-02 12:33:01.992: [ CRSPE][11824]{1:54418:222} Received reply to action [Start] message ID: 797

2016-03-02 12:33:01.992: [ CRSPE][11824]{1:54418:222} RI [ora.shpboss.db 1 1] new internal state: [STABLE] old value: [STARTING]

2016-03-02 12:33:01.993: [ CRSPE][11824]{1:54418:222} Fatal Error from AGFW Proxy: Unable to start the agent process

2016-03-02 12:33:01.993: [ CRSPE][11824]{1:54418:222} Set LAST_SERVER to qzp750707b for [ora.shpboss.db 1 1]

2016-03-02 12:33:01.993: [ CRSPE][11824]{1:54418:222} CRS-2674: Start of 'ora.shpboss.db' on 'qzp750707b' failed

2016-03-02 12:33:01.994: [ CRSPE][11824]{1:54418:222} RI [ora.shpboss.db 1 1] new internal state: [CLEANING] old value: [STABLE]

2016-03-02 12:33:01.994: [ CRSPE][11824]{1:54418:222} Sending message to agfw: id = 898

2016-03-02 12:33:01.994: [ CRSPE][11824]{1:54418:222} CRS-2679: Attempting to clean 'ora.shpboss.db' on 'qzp750707b'

2016-03-02 12:33:01.995: [UiServer][12081]{1:54418:222} Container [ Name: ORDER

MESSAGE:

TextMessage[CRS-2674: Start of 'ora.shpboss.db' on 'qzp750707b' failed]

MSGTYPE:

TextMessage[1]

OBJID:

TextMessage[ora.shpboss.db 1 1]

WAIT:

TextMessage[0]

]

2016-03-02 12:33:01.995: [ COMMCRS][12081]clscsendx: (1117e3430) Connection not active

2016-03-02 12:33:01.995: [UiServer][12081]{1:54418:222} CS(1117e39b0)Error sending msg over socket.6

2016-03-02 12:33:01.996: [ AGFW][10539]{1:54418:222} Agfw Proxy Server received the message: RESOURCE_CLEAN[ora.shpboss.db 1 1] ID 4100:898

2016-03-02 12:33:01.996: [ AGFW][10539]{1:54418:222} Starting the agent: /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent with user id: oracle and incarnation:3

2016-03-02 12:33:02.021: [ AGFW][10539]{1:54418:222} Starting the HB [Interval = 30000, misscount = 6kill allowed=1] for agent: /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent_oracle

2016-03-02 12:33:02.022: [ AGFW][10539]{1:54418:222} Could not forward message [RESOURCE_CLEAN[ora.shpboss.db 1 1] ID 4100:898] to agent. /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent_oracle is not running

2016-03-02 12:33:02.022: [ AGFW][10539]{1:54418:222} Starting of the agent: /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent with user id oracle is already in progress.

2016-03-02 12:33:02.040: [UiServer][12081]{1:54418:222} Communication exception sending reply back to client.FatalCommsException : Failed to send response to client.

(File: clsMessageStream.cpp, line: 275

2016-03-02 12:33:02.040: [UiServer][12081]{1:54418:222} Container [ Name: ORDER

MESSAGE:

TextMessage[CRS-2679: Attempting to clean 'ora.shpboss.db' on 'qzp750707b']

MSGTYPE:

TextMessage[3]

OBJID:

TextMessage[ora.shpboss.db 1 1]

WAIT:

TextMessage[0]

]

2016-03-02 12:33:02.040: [UiServer][12081]{1:54418:222} CS(1117e39b0)No connection to client.6

2016-03-02 12:33:02.041: [UiServer][12081]{1:54418:222} Communication exception sending reply back to client.FatalCommsException : Failed to send response to client.

(File: clsMessageStream.cpp, line: 275

重要的信息已用红色字体标出，大致的意思是，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里都没有报错，悬着的心这才放下。

之前我们曾提到rootcrs.pl -init运行耗时5秒钟就返回了，如果是对于GRID_HOME下所有的文件都检查并修正一边权限和属主5秒钟是远远不够的，这一点相信使用过chmod和chown的童鞋都有体会，经过我的进一步测试发现rootcrs.pl脚本修改的只是$GRID_HOME目录里这些子目录及其下的文件

drwxr-xr-x 17 root oinstall 4096 Feb 23 19:29 crs

drwxrwxr-x 5 grid oinstall 256 Feb 23 19:29 log

drwxrwxr-x 9 grid oinstall 256 Feb 23 19:29 cv

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 grid oinstall 256 Feb 23 19:29 ohasd

drwxr-x--- 3 grid oinstall 256 Feb 23 19:29 mdns

drwxr-x--- 3 root oinstall 256 Feb 23 19:29 gnsd

drwxr-x--- 3 grid oinstall 256 Feb 23 19:29 gipc

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

drwxrwxr-x 5 grid oinstall 256 Feb 23 19:31 cdata

drwxr-x--- 6 grid oinstall 256 Feb 23 19:36 gpnp

drwxrwxr-x 5 grid oinstall 4096 Feb 25 13:07 cfgtoollogs

drwx--x--x 6 grid oinstall 256 Feb 23 19:02 css

drwxr-x--- 7 grid oinstall 256 Feb 23 19:02 evm

从名称上可以看出这些都是GI后台核心进程的工作目录，猜测rootcrs.pl -init的功能只是修复各GI组件密切相关目录与文件的权限，保证GI能够正常启动与停止，但是对于其它目录则不管不问，于是我们可以看到$GRID_HOME目录下仍有大部分目录的权限还处在757

root@qzp750707b:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt

total 176

-rwxr-xrwx 1 grid oinstall 59 Feb 22 16:05 oraInst.loc

drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 demo

drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 csmig

drwxr-xrwx 6 grid oinstall 256 Feb 23 18:57 assistants

drwxr-xrwx 6 grid oinstall 256 Feb 23 18:57 nls

drwxr-xrwx 5 grid oinstall 256 Feb 23 18:57 md

drwxr-xrwx 7 grid oinstall 256 Feb 23 18:57 javavm

drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 hs

drwxr-xrwx 4 grid oinstall 256 Feb 23 18:57 has

drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 diagnostics

drwxr-xrwx 4 grid oinstall 256 Feb 23 18:57 owm

drwxr-xrwx 7 grid oinstall 256 Feb 23 18:57 ord

drwxr-xrwx 4 grid oinstall 256 Feb 23 18:57 oracore

drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 wwg

drwxr-xrwx 5 grid oinstall 256 Feb 23 18:57 usm

。。。。。还有，此处省略了

为避免留下后遗症，我们需要将rootcrs.pl弃之不管的目录与文件的权限、属主也修复一下，怎么修复？MOS 1515018.1提供了现成的perl脚本，这个脚本使用方法很简单：从一台权限正常的服务器上抓取GRID_HOME、ORACLE_HOME下的所有文件与目录权限，生成shell脚本，然后在权限错误的主机上执行这个脚本，简单演示一下：

<1> 先把permission.pl下载下来复制到一台权限正常的服务器上，并赋予执行权限，这台主机上必须要有perl的执行环境

chmod u+x permission.pl

<2> 抓取$ORACLE_HOME下所有目录与文件的属主、权限，可以使用oracle用户或者root用户执行

./permission.pl /oracle/app/oracle/product/11.2.0/db_1

Following log files are generated

logfile : permission-Thu-Mar-10-14-25-31-2016

Command file : restore-perm-Thu-Mar-10-14-25-31-2016.cmd

Linecount : 38734

生成了两个文件，ls -lrt

-rw-r----- 1 oracle oinstall 7890011 Mar 10 14:25 restore-perm-Thu-Mar-10-14-25-31-2016.cmd

-rw-r----- 1 oracle oinstall 4061205 Mar 10 14:25 permission-Thu-Mar-10-14-25-31-2016

其中permission*开头的是/oracle/app/oracle/product/11.2.0/db_1目录及其下的所有子目录与文件列表，例如：

755 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1

640 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/oraInst.loc

750 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/root.sh

755 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage

775 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage/PAF

。。。省略部分内容

restore*开头的包含了执行修改权限修复所需的脚本，例如：

chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1

chmod 755 /oracle/app/oracle/product/11.2.0/db_1

chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/oraInst.loc

chmod 640 /oracle/app/oracle/product/11.2.0/db_1/oraInst.loc

chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/root.sh

chmod 750 /oracle/app/oracle/product/11.2.0/db_1/root.sh

chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage

chmod 755 /oracle/app/oracle/product/11.2.0/db_1/EMStage

chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage/PAF

chmod 775 /oracle/app/oracle/product/11.2.0/db_1/EMStage/PAF

。。。省略部分内容

<3> 抓取$GRID_HOME下所有目录与文件的属主、权限，必须使用root用户执行

./permission.pl /oracle/app/grid/product/11.2.0/grid_1

Following log files are generated

logfile : permission-Thu-Mar-10-14-21-28-2016

Command file : restore-perm-Thu-Mar-10-14-21-28-2016.cmd

Linecount : 60115

结果也生成了两个文件

ls -lrt

-rw-r----- 1 root system 13372037 Mar 10 14:24 restore-perm-Thu-Mar-10-14-24-03-2016.cmd

-rw-r----- 1 root system 6805988 Mar 10 14:24 permission-Thu-Mar-10-14-24-03-2016

<4> 在目标主机上执行restore*开头的两个脚本，root用户执行

将restore*脚本复制到目标主机后，执行

chmod u+x restore-perm-Thu-Mar-10-14-25-31-2016.cmd restore-perm-Thu-Mar-10-14-24-03-2016.cmd

./restore-perm-Thu-Mar-10-14-25-31-2016.cmd

./restore-perm-Thu-Mar-10-14-24-03-2016.cmd

总结：

在安装有GI的环境下，权限、属主是严格被设定的，任何对于它们的错误修改容易引发一系列的问题，而且这些问题往往都很诡异很难按照常规的思路去诊断。万一权限或属主被修改了可以通过rootcrs.pl -init及permission.pl进行修复，rootcrs.pl –init仅修复GI的核心目录，所以其修复速度较快，如果遇到GI无法启动的问题，建议首选这种方法以使GI能够快速启动，但其缺点在于无法全量的进行修复，GI虽然正常了，并不能保证之后的运行过程中不出现这样那样的问题，这时就需要permission.pl出场了，permission.pl的运行模式决定了源库(权限正确的库)与目标库(权限错误的库)间的软件版本尽可能的一致，所以源库一定要选好，否则问题会更糟，另外如果源、目标两个库的安装目录不一样还需要对permission*脚本作调整后再执行。