【Oracle】RAC11gR2 Grid啟動順序及啟動故障診斷思路____Oracle

從11gR2開始，Oracle RAC的架構有了比較大的變化，叢集層面相交於之前的版本有了比較大的變動，原來的rac架構基本上屬於cssd、crsd、evmd三大光禿禿的主幹進程，日誌數量較少，對於rac無法啟動原因，採用最原始的方法逐一查看各個進程的日誌也可找到無法啟動的原因。然而從11gR2之後，叢集層發生了比較大的變動，以下是$GRID_HOME/log/rac1/下的目錄情況：

[grid@rac1 rac1]$ ls

acfs     acfsrepl      acfssec  agent          client   crfmond  cssd   cvu      evmd   gnsd   mdnsd  racg

acfslog  acfsreplroot  admin    alertrac1.log  crflogd  crsd     ctssd  diskmon  gipcd  gpnpd  ohasd  srvm

可以看到在這個目錄中的檔案夾非常多，在rac無法啟動的情況下，如果去所有日誌下查看無法啟動的原因無疑效率極低。所以我們需要一個比較明確的診斷思路。

 

OK，接下來進入正題，希望可以為大家的日常診斷提供協助。

 

第一步，在診斷Grid無法啟動的情況之前我們需要先瞭解11gR2中Grid的啟動流程，下面這張圖比較清晰的說明了現在Grid的啟動順序：

 

從圖中我們可以看到，相比的原來Oracle 10g的叢集架構，11gR2有了比較大的改動。具體的進程作用在這裡不再贅述，不瞭解的可以自己去惡補一下，這裡只說進程啟動順序相關的內容。在啟動叢集的過程中首先啟動的是ohasd進程，在ohasd進程啟動之後會啟動4個agent：

1.cssd agent

以root使用者權限啟動，負責啟動cssd進程。

2.orarootagent

以root使用者權限啟動，負責啟動以下這些守護進程：crsd進程、ctssd進程、Diskmon進程、acfs進程。這些進程也都是以root使用者權限啟動。

3.oraagent

以grid使用者權限啟動，負責mdnsd進程、gipcd進程、gpnpd進程、evmd進程、asm進程（11gR2之後的asm在叢集中被放置到了更底層，和之前版本區別較大）。

4.cssdmonitor。

以root使用者權限啟動，負責cssdmonitor進程的啟動。

 

從圖中我們可以看到之後又由crsd進程負責啟動了兩個agent：orarootagent和oraagent（最後的進程中我們可以看到兩個oraagent進程，就是之前啟動的那個加上這個），之後再由orarootagent和oraagent去負責啟動之後的使用者資源，進程啟動到這裡我認為grid底層啟動完畢，之後再由orarootagent和oraagent啟動的資源出現的問題不再本文的討論範圍內了。

 

第二步，我們已經對grid的進程啟動順序進行了梳理，之後對於grid無法啟動的診斷也就變得簡單。我們只要通過ps -ef|grep /oracle/app/grid/product/11.2.0（$GRID_HOME）就可以瞭解到grid已經啟動到哪一步，哪些進程已經啟動，哪些進程還未啟動，卡在了哪個進程上，這樣我們就能快速找到應該查看的日誌。比如crsd進程沒有啟動，我們就可以通過查看$GRID_HOME/log/rac1/crsd目錄下的crsd.log來進行查看，究竟在crsd進程啟動過程中遭遇了哪些錯誤導致進程無法正常啟動。

 舉例：

[grid@rac1 crsd]$ ps -ef|grep /oracle

root     15235     1  0 14:12 ?        00:00:06 /oracle/app/grid/product/11.2.0/bin/ohasd.bin reboot

grid     15356     1  0 14:12 ?        00:00:00 /oracle/app/grid/product/11.2.0/bin/oraagent.bin

grid     15367     1  0 14:12 ?        00:00:00 /oracle/app/grid/product/11.2.0/bin/mdnsd.bin

grid     15378     1  0 14:12 ?        00:00:02 /oracle/app/grid/product/11.2.0/bin/gpnpd.bin

grid     15388     1  2 14:12 ?        00:00:19 /oracle/app/grid/product/11.2.0/bin/gipcd.bin

root     15390     1  0 14:12 ?        00:00:00 /oracle/app/grid/product/11.2.0/bin/orarootagent.bin

root     15403     1  0 14:12 ?        00:00:08 /oracle/app/grid/product/11.2.0/bin/osysmond.bin

root     15477     1  0 14:12 ?        00:00:02 /oracle/app/grid/product/11.2.0/bin/ologgerd -M -d /oracle/app/grid/product/11.2.0/crf/db/rac1

root     15637     1  0 14:22 ?        00:00:00 /oracle/app/grid/product/11.2.0/bin/cssdmonitor

root     15665     1  0 14:22 ?        00:00:00 /oracle/app/grid/product/11.2.0/bin/cssdagent

grid     15676     1  0 14:22 ?        00:00:00 /oracle/app/grid/product/11.2.0/bin/ocssd.bin

grid     15730 13826  0 14:27 pts/1    00:00:00 grep /oracle

從以上的輸出我們就可以看到，此時grid無法啟動的原因在於cssd進程無法啟動，所以我們直接查看ocssd.log，查看無法啟動的原因，在日誌中找到以下內容：

2016-05-09 14:30:26.476: [    CSSD][1104030016]clssnmvDHBValidateNcopy: node 2, rac2, has a disk HB, but no network HB, DHB has rcfg 358258450, wrtcnt, 177436, LATS 10923264, lastSeqNo 177435, uniqueness 1462763679, timestamp 1462775426/10874194

可以看到是因為私網出現了問題，匯出有disk HB，而沒有network HB，修複私網問題後，叢集可以正常啟動。

 

第三步，附送一篇MOS文章：ID 1623340.1，裡邊羅列了grid各個進程無法啟動的常見原因以及對應的日誌： 1.1.1. 叢集狀態

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

$GRID_HOME/bin/crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

$GRID_HOME/bin/crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        ONLINE  ONLINE       rac1                  Started
ora.crsd
      1        ONLINE  ONLINE       rac1
ora.cssd
      1        ONLINE  ONLINE       rac1
ora.cssdmonitor
      1        ONLINE  ONLINE       rac1
ora.ctssd
      1        ONLINE  ONLINE       rac1                  OBSERVER
ora.diskmon
      1        ONLINE  ONLINE       rac1
ora.drivers.acfs
      1        ONLINE  ONLINE       rac1
ora.evmd
      1        ONLINE  ONLINE       rac1
ora.gipcd
      1        ONLINE  ONLINE       rac1
ora.gpnpd
      1        ONLINE  ONLINE       rac1
ora.mdnsd
      1        ONLINE  ONLINE       rac1

對於11.2.0.2 和以上的版本，會有以下兩個額外的進程：

ora.cluster_interconnect.haip
      1        ONLINE  ONLINE       rac1
ora.crf
      1        ONLINE  ONLINE       rac1

對於11.2.0.3 以上的非EXADATA的系統，ora.diskmon會處於offline的狀態，如下：

ora.diskmon
      1        OFFLINE  OFFLINE       rac1

對於 12c 以上的版本, 會出現ora.storage資源：

ora.storage
1 ONLINE ONLINE racnode1 STABLE

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

$GRID_HOME/bin/crsctl start res ora.crsd -init

  1.1.2. 問題 1: OHASD 無法啟動

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

CRS-4124: Oracle High Availability Services startup failed.
CRS-4000: Command Start failed, or completed with errors.

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

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

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

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

cat /etc/inittab|grep init.ohasd
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

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

找到當前 OS 正在啟動並執行 run level:

who -r

2. "init.ohasd run" 啟動

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

ps -ef|grep init.ohasd|grep -v grep
root      2279     1  0 18:14 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run

注意：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 無法啟動的原因，以下辦法可以作為一個臨時的解決辦法：

 cd <location-of-init.ohasd>
 nohup ./init.ohasd run &

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

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

$GRID_HOME/bin/crsctl enable crs

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

$GRID_HOME/bin/crsctl config crs

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

Feb 29 16:20:36 racnode1 logger: Oracle Cluster Ready Services startup disabled.
Feb 29 16:20:36 racnode1 logger: Could not access /var/opt/oracle/scls_scr/racnode1/root/ohasdstr

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


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

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

（aix /var/adm/syslog    linux /var/log/messages）

Jan 20 20:46:51 rac1 logger: Oracle HA daemon is enabled for autostart.

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

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

From:

    case `$CAT $AUTOSTARTFILE` in
      enable*)
        $LOGERR "Oracle HA daemon is enabled for autostart."

To:

    case `$CAT $AUTOSTARTFILE` in
      enable*)
        /bin/touch /tmp/ohasd.start."`date`"
        $LOGERR "Oracle HA daemon is enabled for autostart."

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

From:

    case `$CAT $AUTOSTARTFILE` in
      enable*)
        $LOGERR "Oracle HA daemon is enabled for autostart."

To:

    case `$CAT $AUTOSTARTFILE` in
      enable*)
        /bin/sleep 120
        $LOGERR "Oracle HA daemon is enabled for autostart."

5.