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*腳本做調整後再執行。

補充說明一點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