診斷 Grid Infrastructure 啟動問題 (文件 ID 1623340.1)

文件內容

適用於:

用途

本文提供了診斷 11GR2 和 12C Grid Infrastructure 啟動問題的方法。對於新安裝的環境（root.sh 和 rootupgrade.sh 執行過程中）和有故障的舊環境都適用。針對 root.sh 的問題，我們可以參考 note 1053970.1 來獲取更多的資訊。

適用範圍

本文適用於叢集/RAC管理員和  支援工程師。

詳細資訊

啟動順序：

簡而言之，負責啟動 ohasd 程式，ohasd 程式啟動 agents 用來啟動守護程式(gipcd, mdnsd, gpnpd, ctssd, ocssd, crsd, evmd ,asm …) ，crsd 啟動 agents 用來啟動使用者資源(database,SCAN,Listener 等)。

如果需要了解更詳細的 Grid Infrastructure Cluster 啟動順序，請參閱 note 1053147.1。

叢集狀態

查詢叢集和守護程式的狀態:

如果守護程式 offline 我們可以透過以下命令啟動:

問題 1: OHASD 無法啟動

由於 ohasd.bin 的責任是直接或者間接的啟動叢集所有的其它程式，所以只有這個程式正常啟動了，其它的程式才能起來，如果 ohasd.bin 的程式沒有起來，當我們檢查資源狀態的時候會報錯 CRS-4639 (Could not contact  High Availability Services); 如果 ohasd.bin 已經啟動了，而再次嘗試啟時，錯誤 CRS-4640 會出現；如果它啟動失敗了，那麼我們會看到以下的錯誤資訊：

自動啟動 ohasd.bin 依賴於以下的配置：

1. 作業系統配置了正確的 run level:

OS 需要在 CRS 啟動之前設定成指定的 run level 來確保 CRS 的正常啟動。

我們可以透過以下方式找到 CRS 需要 OS 設定的 run level：

以上例子展示了，CRS 需要 OS 執行在 run level 3 或 5；請注意，由於作業系統的不同，CRS 啟動需要的 OS 的 run level 也會不同。

找到當前 OS 正在執行的 run level:

2. "init.ohasd run" 啟動

在 /Unix 平臺上，由於"init.ohasd run" 是配置在 /etc/inittab中，程式 init（程式id 1，，Solars和HP-UX上為/sbin/init ，Aix上為/usr/sbin/init）會啟動並且產生"init.ohasd run"程式，如果這個過程失敗了，就不會有"init.ohasd run"的啟動和執行，ohasd.bin 也是無法啟動的：

注意：Oracle Linux (OL6)以及 Red Hat Linux 6 (RHEL6) 已經不再支援 inittab 了，所以 init.ohasd 會被配置在 /etc/init 中，並被 /etc/init 啟動，儘管如此，我們還是應該能看到程式 "/etc/init.d/init.ohasd run" 被啟動；

如果任何 rc Snncommand 的指令碼（在 rcn.d 中，如 S98gcstartup）在啟動的過程中掛死，此時 init 的程式可能無法啟動"/etc/init.d/init.ohasd run"；您需要尋求 OS 廠商的幫助，找到為什麼 Snncommand 指令碼掛死或者無法正常啟動的原因；

錯誤"[ohasd(<pid>)] CRS-0715:Oracle High Availability Service has timed out waiting for init.ohasd to be started." 可能會在 init.ohasd 無法在指定時間內啟動後出現
 
如果系統管理員無法在短期內找到 init.ohasd 無法啟動的原因，以下辦法可以作為一個臨時的解決辦法：

3. Clusterware 自動啟動；--自動啟動預設是開啟的

預設情況下 CRS 自動啟動是開啟的，我們可以透過以下方式開啟：

檢查這個功能是否被開啟:

如果以下資訊被輸出在OS的日誌中

原因是由於這個檔案不存在或者不可訪問，產生這個問題的原因一般是人為的修改或者是打 GI 補丁的過程中使用了錯誤的 opatch (如：使用 Solaris 平臺上的 opatch 在 Linux 上打補丁)


4. syslogd 啟動並且 OS 能夠執行 init 指令碼 S96ohasd

節點啟動之後，OS 可能停滯在一些其它的 Snn 的指令碼上，所以可能沒有機會執行到指令碼 S96ohasd；如果是這種情況，我們不會在 OS 日誌中看到以下資訊

如果在 OS 日誌裡看不到上面的資訊，還有一種可能是 syslogd（(/usr/sbin/syslogd）沒有被完全啟動。GRID 在這種情況下也是無法正常啟動的，這種情況不適用於 AIX 的平臺。

為了瞭解 OS 啟動之後是否能夠執行 S96ohasd 指令碼，可以按照以下的方法修改該指令碼：

From:

To:

重啟節點後，如果您沒有看到檔案 /tmp/ohasd.start.timestamp 被建立，那麼就是說 OS 停滯在其它的 Snn 的指令碼上。如果您能看到 /tmp/ohasd.start.timestamp 生成了，但是"Oracle HA daemon is enabled for autostart"沒有寫入到messages 檔案裡，就是 syslogd 沒有被完全啟動了。以上的兩種情況，您都需要尋求系統管理員的幫助，從 OS 的層面找到問題的原因，對於後一種情況，有個臨時的解決辦法是“休眠”2分鐘， 按照以下的方法修改 ohasd 指令碼：

From:

To:

5. GRID_HOME 所在的檔案系統在執行初始化指令碼 S96ohasd 的時候線上；正常情況下一旦 S96ohasd 執行結束，我們會在 OS message 裡看到以下資訊：

如果您只看到了第一行，沒有看到最後一行的資訊，很可能是 GRID_HOME 所在的檔案系統在指令碼 S96ohasd 執行的時候還沒有正常掛載。


6. Oracle Local Registry  (OLR, $GRID_HOME/cdata/${HOSTNAME}.olr) 有效並可以正常讀寫

如果 OLR 是不可讀寫的或者損壞的，我們會在 ohasd.log 中看到以下的相關資訊

或者

或者

或者

或者

解決辦法就是使用下面的命令，恢復一個好的備份 "ocrconfig -local -restore <ocr_backup_name>"。

預設情況下，OLR 在系統安裝結束後會自動的備份在 $GRID_HOME/cdata/$HOST/backup_$TIME_STAMP.olr 。

7. ohasd.bin可以正常的訪問到網路的 socket 檔案:

在 Grid Infrastructure 環境中，和 ohasd 有關的 socket 檔案屬主應該是 root 使用者，但是在 Oracle Restart 的環境中，他們應該是屬於 grid 使用者的，關於更多的關於網路 socket 檔案許可權和屬主，請參考章節"網路 socket 檔案，屬主和許可權" 給出的例子.

8. ohasd.bin 能夠訪問日誌檔案的位置:

OS messages/syslog 顯示以下資訊:

請參考章節"日誌位置, 屬主和許可權"部分的例子，並確定這些必要的目錄是否有丟失的，並且是按照正確的許可權和屬主建立的。

9. 節點啟動後，在 SUSE Linux 的系統上，ohasd 可能無法啟動，此問題請參考 note 1325718.1 - OHASD not Starting After Reboot on SLES

10. OHASD 無法啟動，使用 "ps -ef| grep ohasd.bin" 顯示 ohasd.bin 的程式已經啟動，但是 $GRID_HOME/log/<node>/ohasd/ohasd.log 在好幾分鐘之後都沒有任何資訊更新,使用 OS 的 truss 工具 可以看到該程式一致在迴圈的執行關閉從未被開啟的檔案控制程式碼的操作:

透過 ohasd.bin 的 Call stack ，可以看到以下資訊:

這是由於  導致的， 該問題在 11.2.0.3 和之上的版本已經被修復,該 bug 的其它症狀還有：叢集的程式無法啟動，而且做 call stack 和 truss 檢視的時候也會看到相同的情況(迴圈的執行 OS 函式 "close") . 如果該 bug 發生在啟動其它的資源時，我們會看到錯誤資訊： "CRS-5802: Unable to start the agent process" 提示。

11. 其它的一些潛在的原因和解決辦法請參見 note 1069182.1 - OHASD Failed to Start: Inappropriate ioctl for device

12. ohasd.bin 正常啟動，但是, "crsctl check crs" 只顯示以下一行資訊:

並且命令 "crsctl stat res -p -init" 無法顯示任何資訊

這個問題是由於 OLR 損壞導致的，請參考 note 1193643.1 進行恢復。

13. 如果 ohasd 仍然無法啟動，請參見 ohasd 的日誌 <grid-home>/log/<nodename>/ohasd/ohasd.log 和 ohasdOUT.log 來獲取更多的資訊；
 

問題 2: OHASD Agents  未啟動

OHASD.BIN 會啟動 4 個 agents/monitors 來啟動其它的資源:

  oraagent: 負責啟動  ora.asm, ora.evmd, ora.gipcd, ora.gpnpd, ora.mdnsd 等
  orarootagent: 負責啟動 ora.crsd, ora.ctssd, ora.diskmon, ora.drivers.acfs 等
  cssdagent / cssdmonitor: 負責啟動 ora.cssd(對應 ocssd.bin) 和 ora.cssdmonitor(對應 cssdmonitor)

如果 ohasd.bin 不能正常地啟動以上任何一個 agents，叢集都無法執行在正常的狀態。

1. 通常情況下，agents 無法啟動的原因是 agent 的日誌或者日誌所在的目錄沒有正確設定屬主和許可權。

關於日誌檔案和資料夾的許可權和屬主設定，請參見章節 "日誌檔案位置, 屬主和許可權" 中的介紹。

2. 如果 agent 的二進位制檔案（oraagent.bin 或者 orarootagent.bin 等）損壞, agent 也將無法啟動，從而導致相關的資源也無法啟動：

解決辦法： 您可以和正常節點上的 agent 檔案進行比較，並且恢復一個好的副本回來。

問題 3: OCSSD.BIN 無法啟動

cssd.bin 的正常啟動依賴於以下幾個必要的條件:

1. GPnP profile 可正常讀寫 - gpnpd  需要完全正常啟動來為profile服務。

如果 ocssd.bin 能夠正常的獲取 profile，通常情況下，我們會在 ocssd.log 中看到以下類似的資訊：

否則，我們會看到以下資訊顯示在 ocssd.log 中。

2. Voting Disk 可以正常讀寫

在 11gR2 的版本中， ocssd.bin 透過 GPnP profile 中的記錄獲取 Voting disk 的資訊, 如果沒有足夠多的選舉盤是可讀寫的，那麼 ocssd.bin 會終止掉自己。

如果所有節點上的 ocssd.bin 因為以下錯誤無法啟動，這是因為 voting file 正在被修改:

解決的辦法是，參照 note 1364971.1 中的步驟，以 exclusive 模式啟動 ocssd.bin。 


如果選舉盤的位置是非 ASM 的裝置，它的許可權和屬主應該是如下顯示：

-rw-r----- 1 ogrid oinstall 21004288 Feb  4 09:13 votedisk1

3. 網路功能是正常的，並且域名解析能夠正常工作:

如果 ocssd.bin 無法正常的繫結到任何網路上，我們會在 ocssd.log 中看到以下類似的日誌資訊：

如果私網上出現了聯通性的故障（包含多播功能關閉），我們會在 ocssd.log 中看到以下類似的日誌資訊：

驗證網路是否正常，請參見：note 1054902.1

如果第三方的叢集管理軟體沒有完全正常啟動，我們在 ocssd.log 中看到以下類似的日誌資訊：

未安裝叢集管理軟體之前，請使用 grid 使用者執行以下操作驗證:

5. 在錯誤的 GRID_HOME 下執行命令"crsctl" 

命令"crsctl" 必須在正確的 GRID_HOME 下執行，才能正常啟動其它程式,否則我們會看到以下的錯誤資訊提示：

問題 4: CRSD.BIN 無法啟動

crsd.bin 的正常啟動依賴於以下幾個必要的條件:

1. ocssd 已經完全正常啟動

如果 ocssd.bin 沒有完全正常啟動，我們會在 crsd.log 中看到以下提示資訊:

2. OCR 可以正常讀寫

如果 OCR 儲存在 ASM 中,那麼 ora.asm 資源(ASM 例項) 必須已經啟動而且 OCR 所在的磁碟組必須已經被掛載,否則我們在 crsd.log 會看到以下的類似資訊：

注意：在11.2 的版本中 ASM 會比 crsd.bin 先啟動，並且會把含有 OCR 的磁碟組自動掛載。


如果您的 OCR 在非 ASM 的儲存中，該檔案的屬主和許可權如下：

-rw-r----- 1 root  oinstall  272756736 Feb  3 23:24 ocr


如果 OCR 是在非 ASM 的儲存中，並且不能被正常訪問，在 crsd.log 會看到以下的類似資訊

如果 OCR 是壞掉了，在 crsd.log 會看到以下的類似資訊:

如果您的 grid 使用者的許可權或者所在組發生了變化，儘管 ASM 還是可以訪問的，在 crsd.log 會看到以下的類似資訊:

如果 GRID_HOME 下的 oracle 二進位制檔案的屬主或者許可權錯誤，儘管 ASM 正常啟動並執行，在 crsd.log 會看到以下的類似資訊：

正常的 GRID_HOME 下該檔案的屬主和許可權應該是如下顯示：

如果 OCR 檔案或者它的映象檔案無法正常訪問 (可能是 ASM 已經啟動, 但是 OCR/mirror 所在的磁碟組沒有掛載),在 crsd.log 會看到以下的類似資訊:

3. crsd.bin 的程式號檔案（<GRID_HOME>/crs/init/<節點名>.pid）存在，但是卻指向其它的程式

如果程式號檔案不存在,在日誌 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我們會看到以下的提示資訊:

解決辦法，我們可以手工建立一個程式號檔案：使用 grid 使用者執行 "touch" 命令，然後重新啟動 ora.crsd 資源。

如果程式號檔案存在，但是記錄的 PID 是指向了其它的程式，而不是 crsd.bin 的程式，在日誌 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我們會看到以下的提示資訊:

在 OS 層面檢查該問題:

解決辦法是，使用 root 使用者，建立一個空的程式號檔案，然後重啟資源 ora.crsd：

4. 網路功能是正常的，並且域名解析能夠正常工作：

如果網路功能不正常，ocssd.bin 程式仍然可能被啟動, 但是 crsd.bin 可能會失敗，同時在 crsd.log 中會提示以下資訊:

或者:

或者:

關於網路和域名解析的驗證，請參考：note 1054902.1

5. crsd 可執行檔案(crsd.bin 和 crsd in GRID_HOME/bin) 的許可權或者屬主正確並且沒有進行過手工的修改, 一個簡單可行的檢查辦法是對比好的節點和壞節點的以下命令輸出 "ls -l <grid-home>/bin/crsd <grid-home>/bin/crsd.bin".


6. 關於CRSD程式啟動問題的進一步深入診斷，請參考 note 1323698.1 - Troubleshooting CRSD Start up Issue
 

問題 5: GPNPD.BIN 無法啟動

1. 網路的域名解析不正常

gpnpd.bin 程式啟動失敗，以下資訊提示在 gpnpd.log 中:

以上的例子，請確定當前節點能夠正常的 ping 到“node2” ，並且確認兩個節點之間沒有任何防火牆。

2. 

由於 , gpnp 的排程執行緒（dispatch thread）可能被阻斷，例如：網路掃描。這個 bug 在 11.2.0.2 GI PSU2，11.2.0.3 及以上版本被修復，具體資訊，請參見 note 10105195.8。

問題 6: 其它的一些守護程式無法啟動

常見原因:

1. 守護程式的日誌檔案或者日誌所在的路徑許可權或者屬主不正確。

如果日誌檔案或者日誌檔案所在的路徑許可權或者屬主設定有問題，通常我們會看到程式嘗試啟動，但是日誌裡的資訊卻始終沒有更新.

關於日誌位置和許可權屬主的限制，請參見 "日誌檔案位置, 屬主和許可權" 獲取更多的資訊。


2. 網路的 socket 檔案許可權或者屬主錯誤

這種情況下，守護程式的日誌會顯示以下資訊:

3. OLR 檔案損壞

這種情況下，守護程式的日誌會顯示以下資訊(以下是個 ora.ctssd 無法啟動的例子):

 
解決辦法，請恢復一個好的OLR的副本，具體辦法請參見 note 1193643.1   
 

問題 7: CRSD Agents 無法啟動

CRSD.BIN 會負責衍生出兩個 agents 程式來啟動使用者的資源，這兩個 agents 的名字和 ohasd.bin 的 agents 的名字相同：

  orarootagent: 負責啟動 ora.netn.network, ora.nodename.vip, ora.scann.vip 和 ora.gns
  oraagent: 負責啟動 ora.asm, ora.eons, ora.ons, listener, SCAN listener, diskgroup, database, service 等資源

我們可以透過以下命令檢視使用者的資源狀態:

如果 crsd.bin 無法正常啟動以上任何一個 agent，使用者的資源都將無法正常啟動.  

1. 通常這些 agent 無法啟動的常見原因是 agent 的日誌或者日誌所在的路徑沒有設定合適的許可權或者屬主。

請參見以下 "日誌檔案位置, 屬主和許可權" 部分關於日誌許可權的設定。

2. agent 可能因為  無法啟動，此時我們會看到 "CRS-5802: Unable to start the agent process"錯誤資訊，請參見 "OHASD 無法啟動"  #10 獲取更多資訊。

問題 8: HAIP 無法啟動

HAIP 無法啟動的原因有很多,例如：

請參見 note 1210883.1 獲取更多關於 HAIP 的資訊。

網路和域名解析的驗證

CRS 的啟動，依賴於網路功能和域名解析的正常工作，如果網路功能或者域名解析不能正常工作，CRS 將無法正常啟動。

關於網路和域名解析的驗證，請參考： note 1054902.1

日誌檔案位置, 屬主和許可權

正確的設定 $GRID_HOME/log 和這裡的子目錄以及檔案對 CRS 元件的正常啟動是至關重要的。

在 Grid Infrastructure 的環境中:

我們假設一個 Grid Infrastructure 環境，節點名字為 rac1, CRS 的屬主是 grid, 並且有兩個單獨的 RDBMS 屬主分別為： rdbmsap 和 rdbmsar，以下是 $GRID_HOME/log 中正常的設定情況:

drwxrwxr-x 5 grid oinstall 4096 Dec  6 09:20 log
  drwxr-xr-x  2 grid oinstall 4096 Dec  6 08:36 crs
  drwxr-xr-t 17 root   oinstall 4096 Dec  6 09:22 rac1
    drwxr-x--- 2 grid oinstall  4096 Dec  6 09:20 admin
    drwxrwxr-t 4 root   oinstall  4096 Dec  6 09:20 agent
      drwxrwxrwt 7 root    oinstall 4096 Jan 26 18:15 crsd
        drwxr-xr-t 2 grid  oinstall 4096 Dec  6 09:40 application_grid
        drwxr-xr-t 2 grid  oinstall 4096 Jan 26 18:15 oraagent_grid
        drwxr-xr-t 2 rdbmsap oinstall 4096 Jan 26 18:15 oraagent_rdbmsap
        drwxr-xr-t 2 rdbmsar oinstall 4096 Jan 26 18:15 oraagent_rdbmsar
        drwxr-xr-t 2 grid  oinstall 4096 Jan 26 18:15 ora_oc4j_type_grid
        drwxr-xr-t 2 root    root     4096 Jan 26 20:09 orarootagent_root
      drwxrwxr-t 6 root oinstall 4096 Dec  6 09:24 ohasd
        drwxr-xr-t 2 grid oinstall 4096 Jan 26 18:14 oraagent_grid
        drwxr-xr-t 2 root   root     4096 Dec  6 09:24 oracssdagent_root
        drwxr-xr-t 2 root   root     4096 Dec  6 09:24 oracssdmonitor_root
        drwxr-xr-t 2 root   root     4096 Jan 26 18:14 orarootagent_root     
    -rw-rw-r-- 1 root root     12931 Jan 26 21:30 alertrac1.log
    drwxr-x--- 2 grid oinstall  4096 Jan 26 20:44 client
    drwxr-x--- 2 root oinstall  4096 Dec  6 09:24 crsd 
    drwxr-x--- 2 grid oinstall  4096 Dec  6 09:24 cssd 
    drwxr-x--- 2 root oinstall  4096 Dec  6 09:24 ctssd
    drwxr-x--- 2 grid oinstall  4096 Jan 26 18:14 diskmon 
    drwxr-x--- 2 grid oinstall  4096 Dec  6 09:25 evmd      
    drwxr-x--- 2 grid oinstall  4096 Jan 26 21:20 gipcd      
    drwxr-x--- 2 root oinstall  4096 Dec  6 09:20 gnsd       
    drwxr-x--- 2 grid oinstall  4096 Jan 26 20:58 gpnpd     
    drwxr-x--- 2 grid oinstall  4096 Jan 26 21:19 mdnsd     
    drwxr-x--- 2 root oinstall  4096 Jan 26 21:20 ohasd      
    drwxrwxr-t 5 grid oinstall  4096 Dec  6 09:34 racg        
      drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgeut
      drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgevtf
      drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgmain
    drwxr-x--- 2 grid oinstall  4096 Jan 26 20:57 srvm        

請注意，絕大部分的子目錄都繼承了父目錄的屬主和許可權，以上僅作為一個參考，來判斷 CRS HOME 中是否有一些遞迴的許可權和屬主改變，如果您已經有一個相同版本的正在執行的工作節點，您可以把該執行的節點作為參考。

在 Oracle Restart 的環境中:

這裡顯示了在 Oracle Restart 環境中 $GRID_HOME/log 目錄下的許可權和屬主設定:

drwxrwxr-x 5 grid oinstall 4096 Oct 31  2009 log
  drwxr-xr-x  2 grid oinstall 4096 Oct 31  2009 crs
  drwxr-xr-x  3 grid oinstall 4096 Oct 31  2009 diag
  drwxr-xr-t 17 root   oinstall 4096 Oct 31  2009 rac1
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 admin
    drwxrwxr-t 4 root   oinstall  4096 Oct 31  2009 agent
      drwxrwxrwt 2 root oinstall 4096 Oct 31  2009 crsd
      drwxrwxr-t 8 root oinstall 4096 Jul 14 08:15 ohasd
        drwxr-xr-x 2 grid oinstall 4096 Aug  5 13:40 oraagent_grid
        drwxr-xr-x 2 grid oinstall 4096 Aug  2 07:11 oracssdagent_grid
        drwxr-xr-x 2 grid oinstall 4096 Aug  3 21:13 orarootagent_grid
    -rwxr-xr-x 1 grid oinstall 13782 Aug  1 17:23 alertrac1.log
    drwxr-x--- 2 grid oinstall  4096 Nov  2  2009 client
    drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 crsd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 cssd
    drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 ctssd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 diskmon
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 evmd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 gipcd
    drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 gnsd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 gpnpd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 mdnsd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 ohasd
    drwxrwxr-t 5 grid oinstall  4096 Oct 31  2009 racg
      drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgeut
      drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgevtf
      drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgmain
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 srvm

網路socket檔案的位置，屬主和許可權

網路的 socket 檔案可能位於目錄： /tmp/.oracle, /var/tmp/.oracle or /usr/tmp/.oracle 中。

當網路的 socket 檔案許可權或者屬主設定不正確的時候，我們通常會在守護程式的日誌中看到以下類似的資訊:

以下錯誤也有可能提示:

解決的辦法：請使用 root 使用者停掉 GI，刪除這些 socket 檔案，並重新啟動 GI。


我們假設一個 Grid Infrastructure 環境，節點名為 rac1, CRS 的屬主是 grid，以下是 socket 資料夾(../.oracle)正常的設定情況:

在 Grid Infrastructure cluster 環境中:

以下例子是叢集環境中的例子：

在 Oracle Restart 環境中:

以下是 Oracle Restart 環境中的輸出例子:

診斷檔案收集

如果透過本文沒有找到問題原因，請使用 root 使用者，在所有的節點上執行 $GRID_HOME/bin/diagcollection.sh ，並上傳在當前目錄下生成所有的 .gz 壓縮檔案來做進一步診斷。

參考