某位仁兄新裝一套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*指令碼作調整後再執行。

補充說明一點rootcrs.pl –init是在PSU>11.2.0.3.6下執行的，如果PSU<11.2.0.3.6可以執行如下兩條命令來實現同樣的效果

<GRID_HOME>/crs/install/rootcrs.pl -unlock

<GRID_HOME>/crs/install/rootcrs.pl -patch

11gR2 GI和DB安裝目錄許可權屬主被修改後的恢復方法

相關文章