【Oracle】RAC11gR2Grid启动顺序及启动故障诊断思路
轉自：https://www.2cto.com/database/201605/507269.html
圖片來自：https://blog.csdn.net/zwjzqqb/article/details/80679508
從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
以上例子展示了，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()] CRS-0715:Oracle High Availability Service has timed out waiting for init.ohasd to be started." 可能會在 init.ohasd 無法在指定時間內啟動后出現
如果系統管理員無法在短期內找到 init.ohasd 無法啟動的原因，以下辦法可以作為一個臨時的解決辦法：
cd
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. GRID_HOME 所在的文件系統在執行初始化腳本 S96ohasd 的時候在線；正常情況下一旦 S96ohasd 執行結束，我們會在 OS message 里看到以下信息：
Jan 20 20:46:51 rac1 logger: Oracle HA daemon is enabled for autostart.
..
Jan 20 20:46:57 rac1 logger: exec /ocw/grid/perl/bin/perl -I/ocw/grid/perl/lib /ocw/grid/bin/crswrapexece.pl /ocw/grid/crs/install/s_crsconfig_rac1_env.txt /ocw/grid/bin/ohasd.bin "reboot"
如果您只看到了第一行，沒有看到最后一行的信息，很可能是 GRID_HOME 所在的文件系統在腳本 S96ohasd 執行的時候還沒有正常掛載。
6. Oracle Local Registry (OLR, $GRID_HOME/cdata/${HOSTNAME}.olr) 有效并可以正常讀寫
ls -l $GRID_HOME/cdata/*.olr
-rw------- 1 root oinstall 272756736 Feb 2 18:20 rac1.olr
如果 OLR 是不可讀寫的或者損壞的，我們會在 ohasd.log 中看到以下的相關信息
..
2010-01-24 22:59:10.470: [ default][1373676464] Initializing OLR
2010-01-24 22:59:10.472: [ OCROSD][1373676464]utopen:6m':failed in stat OCR file/disk /ocw/grid/cdata/rac1.olr, errno=2, os err string=No such file or directory
2010-01-24 22:59:10.472: [ OCROSD][1373676464]utopen:7:failed to open any OCR file/disk, errno=2, os err string=No such file or directory
2010-01-24 22:59:10.473: [ OCRRAW][1373676464]proprinit: Could not open raw device
2010-01-24 22:59:10.473: [ OCRAPI][1373676464]a_init:16!: Backend init unsuccessful : [26]
2010-01-24 22:59:10.473: [ CRSOCR][1373676464] OCR context init failure. Error: PROCL-26: Error while accessing the physical storage Operating System error [No such file or directory] [2]
2010-01-24 22:59:10.473: [ default][1373676464] OLR initalization failured, rc=26
2010-01-24 22:59:10.474: [ default][1373676464]Created alert : (:OHAS00106:) : Failed to initialize Oracle Local Registry
2010-01-24 22:59:10.474: [ default][1373676464][PANIC] OHASD exiting; Could not init OLR
或者
..
2010-01-24 23:01:46.275: [ OCROSD][1228334000]utread:3: Problem reading buffer 1907f000 buflen 4096 retval 0 phy_offset 102400 retry 5
2010-01-24 23:01:46.275: [ OCRRAW][1228334000]propriogid:1_1: Failed to read the whole bootblock. Assumes invalid format.
2010-01-24 23:01:46.275: [ OCRRAW][1228334000]proprioini: all disks are not OCR/OLR formatted
2010-01-24 23:01:46.275: [ OCRRAW][1228334000]proprinit: Could not open raw device
2010-01-24 23:01:46.275: [ OCRAPI][1228334000]a_init:16!: Backend init unsuccessful : [26]
2010-01-24 23:01:46.276: [ CRSOCR][1228334000] OCR context init failure. Error: PROCL-26: Error while accessing the physical storage
2010-01-24 23:01:46.276: [ default][1228334000] OLR initalization failured, rc=26
2010-01-24 23:01:46.276: [ default][1228334000]Created alert : (:OHAS00106:) : Failed to initialize Oracle Local Registry
2010-01-24 23:01:46.277: [ default][1228334000][PANIC] OHASD exiting; Could not init OLR
或者
..
2010-11-07 03:00:08.932: [ default][1] Created alert : (:OHAS00102:) : OHASD is not running as privileged user
2010-11-07 03:00:08.932: [ default][1][PANIC] OHASD exiting: must be run as privileged user
或者
ohasd.bin comes up but output of "crsctl stat res -t -init"shows no resource, and "ocrconfig -local -manualbackup" fails
或者
..
2010-08-04 13:13:11.102: [ CRSPE][35] Resources parsed
2010-08-04 13:13:11.103: [ CRSPE][35] Server [] has been registered with the PE data model
2010-08-04 13:13:11.103: [ CRSPE][35] STARTUPCMD_REQ = false:
2010-08-04 13:13:11.103: [ CRSPE][35] Server [] has changed state from [Invalid/unitialized] to [VISIBLE]
2010-08-04 13:13:11.103: [ CRSOCR][31] Multi Write Batch processing...
2010-08-04 13:13:11.103: [ default][35] Dump State Starting ...
..
2010-08-04 13:13:11.112: [ CRSPE][35] SERVERS:
:VISIBLE:address{{Absolute|Node:0|Process:-1|Type:1}}; recovered state:VISIBLE. Assigned to no pool
------------- SERVER POOLS:
Free [min:0][max:-1][importance:0] NO SERVERS ASSIGNED
2010-08-04 13:13:11.113: [ CRSPE][35] Dumping ICE contents...:ICE operation count: 0
2010-08-04 13:13:11.113: [ default][35] Dump State Done.
解決辦法就是使用下面的命令，恢復一個好的備份 "ocrconfig -local -restore "。
默認情況下，OLR 在系統安裝結束后會自動的備份在 $GRID_HOME/cdata/$HOST/backup_$TIME_STAMP.olr 。
7. ohasd.bin可以正常的訪問到網絡的 socket 文件:
2010-06-29 10:31:01.570: [ COMMCRS][1206901056]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=procr_local_conn_0_PROL))
2010-06-29 10:31:01.571: [ OCRSRV][1217390912]th_listen: CLSCLISTEN failed clsc_ret= 3, addr= [(ADDRESS=(PROTOCOL=ipc)(KEY=procr_local_conn_0_PROL))]
2010-06-29 10:31:01.571: [ OCRSRV][3267002960]th_init: Local listener did not reach valid state
在 Grid Infrastructure 環境中，和 ohasd 有關的 socket 文件屬主應該是 root 用戶，但是在 Oracle Restart 的環境中，他們應該是屬于 grid 用戶的，關于更多的關于網絡 socket 文件權限和屬主，請參考章節"網絡 socket 文件，屬主和權限" 給出的例子.
8. ohasd.bin 能夠訪問日志文件的位置:
OS messages/syslog 顯示以下信息:
Feb 20 10:47:08 racnode1 OHASD[9566]: OHASD exiting; Directory /ocw/grid/log/racnode1/ohasd not found.
請參考章節"日志位置, 屬主和權限"部分的例子，并確定這些必要的目錄是否有丟失的，并且是按照正確的權限和屬主創建的。
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//ohasd/ohasd.log 在好幾分鐘之后都沒有任何信息更新,使用 OS 的 truss 工具 可以看到該進程一致在循環的執行關閉從未被打開的文件句柄的操作:
..
15058/1: 0.1995 close(2147483646) Err#9 EBADF
15058/1: 0.1996 close(2147483645) Err#9 EBADF
..
通過 ohasd.bin 的 Call stack ，可以看到以下信息:
_close sclssutl_closefiledescriptors main ..
這是由于 bug 11834289 導致的， 該問題在 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" 只顯示以下一行信息:
CRS-4638: Oracle High Availability Services is online
并且命令 "crsctl stat res -p -init" 無法顯示任何信息
這個問題是由于 OLR 損壞導致的，請參考 note 1193643.1 進行恢復。
13. 如果 ohasd 仍然無法啟動，請參見 ohasd 的日志 /log//ohasd/ohasd.log 和 ohasdOUT.log 來獲取更多的信息；
1.1.3. 問題 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 也將無法啟動，從而導致相關的資源也無法啟動：
2011-05-03 11:11:13.189
[ohasd(25303)]CRS-5828:Could not start agent '/ocw/grid/bin/orarootagent_grid'. Details at (:CRSAGF00130:) {0:0:2} in /ocw/grid/log/racnode1/ohasd/ohasd.log.
2011-05-03 12:03:17.491: [ AGFW][1117866336] {0:0:184} Created alert : (:CRSAGF00130:) : Failed to start the agent /ocw/grid/bin/orarootagent_grid
2011-05-03 12:03:17.491: [ AGFW][1117866336] {0:0:184} Agfw Proxy Server sending the last reply to PE for message:RESOURCE_START[ora.diskmon 1 1] ID 4098:403
2011-05-03 12:03:17.491: [ AGFW][1117866336] {0:0:184} Can not stop the agent: /ocw/grid/bin/orarootagent_grid because pid is not initialized
..
2011-05-03 12:03:17.492: [ CRSPE][1128372576] {0:0:184} Fatal Error from AGFW Proxy: Unable to start the agent process
2011-05-03 12:03:17.492: [ CRSPE][1128372576] {0:0:184} CRS-2674: Start of 'ora.diskmon' on 'racnode1' failed
..
2011-06-27 22:34:57.805: [ AGFW][1131669824] {0:0:2} Created alert : (:CRSAGF00123:) : Failed to start the agent process: /ocw/grid/bin/cssdagent Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/ocw/grid/bin/cssdagent]
2011-06-27 22:34:57.805: [ AGFW][1131669824] {0:0:2} Created alert : (:CRSAGF00126:) : Agent start failed
..
2011-06-27 22:34:57.806: [ AGFW][1131669824] {0:0:2} Created alert : (:CRSAGF00123:) : Failed to start the agent process: /ocw/grid/bin/cssdmonitor Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/ocw/grid/bin/cssdmonitor]
解決辦法： 您可以和正常節點上的 agent 文件進行比較，并且恢復一個好的副本回來。
1.1.4. 問題 3: OCSSD.BIN 無法啟動
cssd.bin 的正常啟動依賴于以下幾個必要的條件:
1. GPnP profile 可正常讀寫 - gpnpd 需要完全正常啟動來為profile服務。
如果 ocssd.bin 能夠正常的獲取 profile，通常情況下，我們會在 ocssd.log 中看到以下類似的信息：
2010-02-02 18:00:16.251: [ GPnP][408926240]clsgpnpm_exchange: [at clsgpnpm.c:1175] Calling "ipc://GPNPD_rac1", try 4 of 500...
2010-02-02 18:00:16.263: [ GPnP][408926240]clsgpnp_profileVerifyForCall: [at clsgpnp.c:1867] Result: (87) CLSGPNP_SIG_VALPEER. Profile verified. prf=0x165160d0
2010-02-02 18:00:16.263: [ GPnP][408926240]clsgpnp_profileGetSequenceRef: [at clsgpnp.c:841] Result: (0) CLSGPNP_OK. seq of p=0x165160d0 is '6'=6
2010-02-02 18:00:16.263: [ GPnP][408926240]clsgpnp_profileCallUrlInt: [at clsgpnp.c:2186] Result: (0) CLSGPNP_OK. Successful get-profile CALL to remote "ipc://GPNPD_rac1" disco ""
否則，我們會看到以下信息顯示在 ocssd.log 中。
2010-02-03 22:26:17.057: [ GPnP][3852126240]clsgpnpm_connect: [at clsgpnpm.c:1100] GIPC gipcretConnectionRefused (29) gipcConnect(ipc-ipc://GPNPD_rac1)
2010-02-03 22:26:17.057: [ GPnP][3852126240]clsgpnpm_connect: [at clsgpnpm.c:1101] Result: (48) CLSGPNP_COMM_ERR. Failed to connect to call url "ipc://GPNPD_rac1"
2010-02-03 22:26:17.057: [ GPnP][3852126240]clsgpnp_getProfileEx: [at clsgpnp.c:546] Result: (13) CLSGPNP_NO_DAEMON. Can't get GPnP service profile from local GPnP daemon
2010-02-03 22:26:17.057: [ default][3852126240]Cannot get GPnP profile. Error CLSGPNP_NO_DAEMON (GPNPD daemon is not running).
2010-02-03 22:26:17.057: [ CSSD][3852126240]clsgpnp_getProfile failed, rc(13)
2. Voting Disk 可以正常讀寫
在 11gR2 的版本中， ocssd.bin 通過 GPnP profile 中的記錄獲取 Voting disk 的信息, 如果沒有足夠多的選舉盤是可讀寫的，那么 ocssd.bin 會終止掉自己。
2010-02-03 22:37:22.212: [ CSSD][2330355744]clssnmReadDiscoveryProfile: voting file discovery string(/share/storage/di*)
..
2010-02-03 22:37:22.227: [ CSSD][1145538880]clssnmvDiskVerify: Successful discovery of 0 disks
2010-02-03 22:37:22.227: [ CSSD][1145538880]clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2010-02-03 22:37:22.227: [ CSSD][1145538880]clssnmvFindInitialConfigs: No voting files found
2010-02-03 22:37:22.228: [ CSSD][1145538880]###################################
2010-02-03 22:37:22.228: [ CSSD][1145538880]clssscExit: CSSD signal 11 in thread clssnmvDDiscThread
如果所有節點上的 ocssd.bin 因為以下錯誤無法啟動，這是因為 voting file 正在被修改:
2010-05-02 03:11:19.033: [ CSSD][1197668093]clssnmCompleteInitVFDiscovery: Detected voting file add in progress for CIN 0:1134513465:0, waiting for configuration to complete 0:1134513098:0
解決的辦法是，參照 note 1364971.1 中的步驟，以 exclusive 模式啟動 ocssd.bin。
如果選舉盤的位置是非 ASM 的設備，它的權限和屬主應該是如下顯示：
-rw-r----- 1 ogrid oinstall 21004288 Feb 4 09:13 votedisk1
3. 網絡功能是正常的，并且域名解析能夠正常工作:
如果 ocssd.bin 無法正常的綁定到任何網絡上，我們會在 ocssd.log 中看到以下類似的日志信息：
2010-02-03 23:26:25.804: [GIPCXCPT][1206540320]gipcmodGipcPassInitializeNetwork: failed to find any interfaces in clsinet, ret gipcretFail (1)
2010-02-03 23:26:25.804: [GIPCGMOD][1206540320]gipcmodGipcPassInitializeNetwork: EXCEPTION[ ret gipcretFail (1) ] failed to determine host from clsinet, using default
..
2010-02-03 23:26:25.810: [ CSSD][1206540320]clsssclsnrsetup: gipcEndpoint failed, rc 39
2010-02-03 23:26:25.811: [ CSSD][1206540320]clssnmOpenGIPCEndp: failed to listen on gipc addr gipc://rac1:nm_eotcs- ret 39
2010-02-03 23:26:25.811: [ CSSD][1206540320]clssscmain: failed to open gipc endp
如果私網上出現了聯通性的故障（包含多播功能關閉），我們會在 ocssd.log 中看到以下類似的日志信息：
2010-09-20 11:52:54.014: [ CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 453, LATS 328297844, lastSeqNo 452, uniqueness 1284979488, timestamp 1284979973/329344894
2010-09-20 11:52:54.016: [ CSSD][1078421824]clssgmWaitOnEventValue: after CmInfo State val 3, eval 1 waited 0
.. >>>> after a long delay
2010-09-20 12:02:39.578: [ CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 1037, LATS 328883434, lastSeqNo 1036, uniqueness 1284979488, timestamp 1284980558/329930254
2010-09-20 12:02:39.895: [ CSSD][1107286336]clssgmExecuteClientRequest: MAINT recvd from proc 2 (0xe1ad870)
2010-09-20 12:02:39.895: [ CSSD][1107286336]clssgmShutDown: Received abortive shutdown request from client.
2010-09-20 12:02:39.895: [ CSSD][1107286336]###################################
2010-09-20 12:02:39.895: [ CSSD][1107286336]clssscExit: CSSD aborting from thread GMClientListener
2010-09-20 12:02:39.895: [ CSSD][1107286336]###################################
驗證網絡是否正常，請參見：note 1054902.1
$GRID_HOME/bin/lsnodes -n
racnode1 1
racnode1 0
如果第三方的集群管理軟件沒有完全正常啟動，我們在 ocssd.log 中看到以下類似的日志信息：
2010-08-30 18:28:13.207: [ CSSD][36]clssnm_skgxninit: skgxncin failed, will retry
2010-08-30 18:28:14.207: [ CSSD][36]clssnm_skgxnmon: skgxn init failed
2010-08-30 18:28:14.208: [ CSSD][36]###################################
2010-08-30 18:28:14.208: [ CSSD][36]clssscExit: CSSD signal 11 in thread skgxnmon
未安裝集群管理軟件之前，請使用 grid 用戶執行以下操作驗證:
$INSTALL_SOURCE/install/lsnodes -v
5. 在錯誤的 GRID_HOME 下執行命令"crsctl"
命令"crsctl" 必須在正確的 GRID_HOME 下執行，才能正常啟動其它進程,否則我們會看到以下的錯誤信息提示：
2012-11-14 10:21:44.014: [ CSSD][1086675264]ASSERT clssnm1.c 3248
2012-11-14 10:21:44.014: [ CSSD][1086675264](:CSSNM00056:)clssnmvStartDiscovery: Terminating because of the release version(11.2.0.2.0) of this node being lesser than the active version(11.2.0.3.0) that the cluster is at
2012-11-14 10:21:44.014: [ CSSD][1086675264]###################################
2012-11-14 10:21:44.014: [ CSSD][1086675264]clssscExit: CSSD aborting from thread clssnmvDDiscThread#
1.1.5. 問題 4: CRSD.BIN 無法啟動
crsd.bin 的正常啟動依賴于以下幾個必要的條件:
1. ocssd 已經完全正常啟動
如果 ocssd.bin 沒有完全正常啟動，我們會在 crsd.log 中看到以下提示信息:
2010-02-03 22:37:51.638: [ CSSCLNT][1548456880]clssscConnect: gipc request failed with 29 (0x16)
2010-02-03 22:37:51.638: [ CSSCLNT][1548456880]clsssInitNative: connect failed, rc 29
2010-02-03 22:37:51.639: [ CRSRTI][1548456880] CSS is not ready. Received status 3 from CSS. Waiting for good status ..
2. OCR 可以正常讀寫
如果 OCR 保存在 ASM 中,那么 ora.asm 資源(ASM 實例) 必須已經啟動而且 OCR 所在的磁盤組必須已經被掛載,否則我們在 crsd.log 會看到以下的類似信息：
2010-02-03 22:22:55.186: [ OCRASM][2603807664]proprasmo: Error in open/create file in dg [GI]
[ OCRASM][2603807664]SLOS : SLOS: cat=7, opn=kgfoAl06, dep=15077, loc=kgfokge
ORA-15077: could not locate ASM instance serving a required diskgroup
2010-02-03 22:22:55.189: [ OCRASM][2603807664]proprasmo: kgfoCheckMount returned [7]
2010-02-03 22:22:55.189: [ OCRASM][2603807664]proprasmo: The ASM instance is down
2010-02-03 22:22:55.190: [ OCRRAW][2603807664]proprioo: Failed to open [+GI]. Returned proprasmo() with [26]. Marking location as UNAVAILABLE.
2010-02-03 22:22:55.190: [ OCRRAW][2603807664]proprioo: No OCR/OLR devices are usable
2010-02-03 22:22:55.190: [ OCRASM][2603807664]proprasmcl: asmhandle is NULL
2010-02-03 22:22:55.190: [ OCRRAW][2603807664]proprinit: Could not open raw device
2010-02-03 22:22:55.190: [ OCRASM][2603807664]proprasmcl: asmhandle is NULL
2010-02-03 22:22:55.190: [ OCRAPI][2603807664]a_init:16!: Backend init unsuccessful : [26]
2010-02-03 22:22:55.190: [ CRSOCR][2603807664] OCR context init failure. Error: PROC-26: Error while accessing the physical storage ASM error [SLOS: cat=7, opn=kgfoAl06, dep=15077, loc=kgfokge
ORA-15077: could not locate ASM instance serving a required diskgroup
] [7]
2010-02-03 22:22:55.190: [ CRSD][2603807664][PANIC] CRSD exiting: Could not init OCR, code: 26
注意：在11.2 的版本中 ASM 會比 crsd.bin 先啟動，并且會把含有 OCR 的磁盤組自動掛載。
如果您的 OCR 在非 ASM 的存儲中，該文件的屬主和權限如下：
-rw-r----- 1 root oinstall 272756736 Feb 3 23:24 ocr
如果 OCR 是在非 ASM 的存儲中，并且不能被正常訪問，在 crsd.log 會看到以下的類似信息
2010-02-03 23:14:33.583: [ OCROSD][2346668976]utopen:7:failed to open any OCR file/disk, errno=2, os err string=No such file or directory
2010-02-03 23:14:33.583: [ OCRRAW][2346668976]proprinit: Could not open raw device
2010-02-03 23:14:33.583: [ default][2346668976]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:14:34.587: [ OCROSD][2346668976]utopen:6m':failed in stat OCR file/disk /share/storage/ocr, errno=2, os err string=No such file or directory
2010-02-03 23:14:34.587: [ OCROSD][2346668976]utopen:7:failed to open any OCR file/disk, errno=2, os err string=No such file or directory
2010-02-03 23:14:34.587: [ OCRRAW][2346668976]proprinit: Could not open raw device
2010-02-03 23:14:34.587: [ default][2346668976]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:14:35.589: [ CRSD][2346668976][PANIC] CRSD exiting: OCR device cannot be initialized, error: 1:26
如果 OCR 是壞掉了，在 crsd.log 會看到以下的類似信息:
2010-02-03 23:19:38.417: [ default][3360863152]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:19:39.429: [ OCRRAW][3360863152]propriogid:1_2: INVALID FORMAT
2010-02-03 23:19:39.429: [ OCRRAW][3360863152]proprioini: all disks are not OCR/OLR formatted
2010-02-03 23:19:39.429: [ OCRRAW][3360863152]proprinit: Could not open raw device
2010-02-03 23:19:39.429: [ default][3360863152]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:19:40.432: [ CRSD][3360863152][PANIC] CRSD exiting: OCR device cannot be initialized, error: 1:26
如果您的 grid 用戶的權限或者所在組發生了變化，盡管 ASM 還是可以訪問的，在 crsd.log 會看到以下的類似信息:
2010-03-10 11:45:12.510: [ OCRASM][611467760]proprasmo: Error in open/create file in dg [SYSTEMDG]
[ OCRASM][611467760]SLOS : SLOS: cat=7, opn=kgfoAl06, dep=1031, loc=kgfokge
ORA-01031: insufficient privileges
2010-03-10 11:45:12.528: [ OCRASM][611467760]proprasmo: kgfoCheckMount returned [7]
2010-03-10 11:45:12.529: [ OCRASM][611467760]proprasmo: The ASM instance is down
2010-03-10 11:45:12.529: [ OCRRAW][611467760]proprioo: Failed to open [+SYSTEMDG]. Returned proprasmo() with [26]. Marking location as UNAVAILABLE.
2010-03-10 11:45:12.529: [ OCRRAW][611467760]proprioo: No OCR/OLR devices are usable
2010-03-10 11:45:12.529: [ OCRASM][611467760]proprasmcl: asmhandle is NULL
2010-03-10 11:45:12.529: [ OCRRAW][611467760]proprinit: Could not open raw device
2010-03-10 11:45:12.529: [ OCRASM][611467760]proprasmcl: asmhandle is NULL
2010-03-10 11:45:12.529: [ OCRAPI][611467760]a_init:16!: Backend init unsuccessful : [26]
2010-03-10 11:45:12.530: [ CRSOCR][611467760] OCR context init failure. Error: PROC-26: Error while accessing the physical storage ASM error [SLOS: cat=7, opn=kgfoAl06, dep=1031, loc=kgfokge
ORA-01031: insufficient privileges
] [7]
如果 GRID_HOME 下的 oracle 二進制文件的屬主或者權限錯誤，盡管 ASM 正常啟動并運行，在 crsd.log 會看到以下的類似信息：
2012-03-04 21:34:23.139: [ OCRASM][3301265904]proprasmo: Error in open/create file in dg [OCR]
[ OCRASM][3301265904]SLOS : SLOS: cat=7, opn=kgfoAl06, dep=12547, loc=kgfokge
2012-03-04 21:34:23.139: [ OCRASM][3301265904]ASM Error Stack : ORA-12547: TNS:lost contact
2012-03-04 21:34:23.633: [ OCRASM][3301265904]proprasmo: kgfoCheckMount returned [7]
2012-03-04 21:34:23.633: [ OCRASM][3301265904]proprasmo: The ASM instance is down
2012-03-04 21:34:23.634: [ OCRRAW][3301265904]proprioo: Failed to open [+OCR]. Returned proprasmo() with [26]. Marking location as UNAVAILABLE.
2012-03-04 21:34:23.634: [ OCRRAW][3301265904]proprioo: No OCR/OLR devices are usable
2012-03-04 21:34:23.635: [ OCRASM][3301265904]proprasmcl: asmhandle is NULL
2012-03-04 21:34:23.636: [ GIPC][3301265904] gipcCheckInitialization: possible incompatible non-threaded init from [prom.c : 690], original from [clsss.c : 5326]
2012-03-04 21:34:23.639: [ default][3301265904]clsvactversion:4: Retrieving Active Version from local storage.
2012-03-04 21:34:23.643: [ OCRRAW][3301265904]proprrepauto: The local OCR configuration matches with the configuration published by OCR Cache Writer. No repair required.
2012-03-04 21:34:23.645: [ OCRRAW][3301265904]proprinit: Could not open raw device
2012-03-04 21:34:23.646: [ OCRASM][3301265904]proprasmcl: asmhandle is NULL
2012-03-04 21:34:23.650: [ OCRAPI][3301265904]a_init:16!: Backend init unsuccessful : [26]
2012-03-04 21:34:23.651: [ CRSOCR][3301265904] OCR context init failure. Error: PROC-26: Error while accessing the physical storage
ORA-12547: TNS:lost contact
2012-03-04 21:34:23.652: [ CRSMAIN][3301265904] Created alert : (:CRSD00111:) : Could not init OCR, error: PROC-26: Error while accessing the physical storage
ORA-12547: TNS:lost contact
2012-03-04 21:34:23.652: [ CRSD][3301265904][PANIC] CRSD exiting: Could not init OCR, code: 26
正常的 GRID_HOME 下該文件的屬主和權限應該是如下顯示：
-rwsr-s--x 1 grid oinstall 184431149 Feb 2 20:37 /ocw/grid/bin/oracle
如果 OCR 文件或者它的鏡像文件無法正常訪問 (可能是 ASM 已經啟動, 但是 OCR/mirror 所在的磁盤組沒有掛載),在 crsd.log 會看到以下的類似信息:
2010-05-11 11:16:38.578: [ OCRASM][18]proprasmo: Error in open/create file in dg [OCRMIR]
[ OCRASM][18]SLOS : SLOS: cat=8, opn=kgfoOpenFile01, dep=15056, loc=kgfokge
ORA-17503: ksfdopn:DGOpenFile05 Failed to open file +OCRMIR.255.4294967295
ORA-17503: ksfdopn:2 Failed to open file +OCRMIR.255.4294967295
ORA-15001: diskgroup "OCRMIR
..
2010-05-11 11:16:38.647: [ OCRASM][18]proprasmo: kgfoCheckMount returned [6]
2010-05-11 11:16:38.648: [ OCRASM][18]proprasmo: The ASM disk group OCRMIR is not found or not mounted
2010-05-11 11:16:38.648: [ OCRASM][18]proprasmdvch: Failed to open OCR location [+OCRMIR] error [26]
2010-05-11 11:16:38.648: [ OCRRAW][18]propriodvch: Error [8] returned device check for [+OCRMIR]
2010-05-11 11:16:38.648: [ OCRRAW][18]dev_replace: non-master could not verify the new disk (8)
[ OCRSRV][18]proath_invalidate_action: Failed to replace [+OCRMIR] [8]
[ OCRAPI][18]procr_ctx_set_invalid_no_abort: ctx set to invalid
..
2010-05-11 11:16:46.587: [ OCRMAS][19]th_master:91: Comparing device hash ids between local and master failed
2010-05-11 11:16:46.587: [ OCRMAS][19]th_master:91 Local dev (1862408427, 1028247821, 0, 0, 0)
2010-05-11 11:16:46.587: [ OCRMAS][19]th_master:91 Master dev (1862408427, 1859478705, 0, 0, 0)
2010-05-11 11:16:46.587: [ OCRMAS][19]th_master:9: Shutdown CacheLocal. my hash ids don't match
[ OCRAPI][19]procr_ctx_set_invalid_no_abort: ctx set to invalid
[ OCRAPI][19]procr_ctx_set_invalid: aborting...
2010-05-11 11:16:46.587: [ CRSD][19] Dump State Starting ...
3. crsd.bin 的進程號文件（/crs/init/<節點名>.pid）存在，但是卻指向其它的進程
如果進程號文件不存在,在日志 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我們會看到以下的提示信息:
2010-02-14 17:40:57.927: [ora.crsd][1243486528] [check] PID FILE doesn't exist.
..
2010-02-14 17:41:57.927: [ clsdmt][1092499776]Creating PID [30269] file for home /ocw/grid host racnode1 bin crs to /ocw/grid/crs/init/
2010-02-14 17:41:57.927: [ clsdmt][1092499776]Error3 -2 writing PID [30269] to the file []
2010-02-14 17:41:57.927: [ clsdmt][1092499776]Failed to record pid for CRSD
2010-02-14 17:41:57.927: [ clsdmt][1092499776]Terminating process
2010-02-14 17:41:57.927: [ default][1092499776] CRSD exiting on stop request from clsdms_thdmai
解決辦法，我們可以手工創建一個進程號文件：使用 grid 用戶執行 "touch" 命令，然后重新啟動 ora.crsd 資源。
如果進程號文件存在，但是記錄的 PID 是指向了其它的進程，而不是 crsd.bin 的進程，在日志 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我們會看到以下的提示信息:
2011-04-06 15:53:38.777: [ora.crsd][1160390976] [check] PID will be looked for in /ocw/grid/crs/init/racnode1.pid
2011-04-06 15:53:38.778: [ora.crsd][1160390976] [check] PID which will be monitored will be 1535 >> 1535 is output of "cat /ocw/grid/crs/init/racnode1.pid"
2011-04-06 15:53:38.965: [ COMMCRS][1191860544]clsc_connect: (0x2aaab400b0b0) no listener at (ADDRESS=(PROTOCOL=ipc)(KEY=racnode1DBG_CRSD))
[ clsdmc][1160390976]Fail to connect (ADDRESS=(PROTOCOL=ipc)(KEY=racnode1DBG_CRSD)) with status 9
2011-04-06 15:53:38.966: [ora.crsd][1160390976] [check] Error = error 9 encountered when connecting to CRSD
2011-04-06 15:53:39.023: [ora.crsd][1160390976] [check] Calling PID check for daemon
2011-04-06 15:53:39.023: [ora.crsd][1160390976] [check] Trying to check PID = 1535
2011-04-06 15:53:39.203: [ora.crsd][1160390976] [check] PID check returned ONLINE CLSDM returned OFFLINE
2011-04-06 15:53:39.203: [ora.crsd][1160390976] [check] DaemonAgent::check returned 5
2011-04-06 15:53:39.203: [ AGFW][1160390976] check for resource: ora.crsd 1 1 completed with status: FAILED
2011-04-06 15:53:39.203: [ AGFW][1170880832] ora.crsd 1 1 state changed from: UNKNOWN to: FAILED
..
2011-04-06 15:54:10.511: [ AGFW][1167522112] ora.crsd 1 1 state changed from: UNKNOWN to: CLEANING
..
2011-04-06 15:54:10.513: [ora.crsd][1146542400] [clean] Trying to stop PID = 1535
..
2011-04-06 15:54:11.514: [ora.crsd][1146542400] [clean] Trying to check PID = 1535
在 OS 層面檢查該問題:
ls -l /ocw/grid/crs/init/*pid
-rwxr-xr-x 1 ogrid oinstall 5 Feb 17 11:00 /ocw/grid/crs/init/racnode1.pid
cat /ocw/grid/crs/init/*pid
1535
ps -ef| grep 1535
root 1535 1 0 Mar30 ? 00:00:00 iscsid >> 注意：進程 1535 不是 crsd.bin
解決辦法是，使用 root 用戶，創建一個空的進程號文件，然后重啟資源 ora.crsd：
# > $GRID_HOME/crs/init/.pid
# $GRID_HOME/bin/crsctl stop res ora.crsd -init
# $GRID_HOME/bin/crsctl start res ora.crsd -init
4. 網絡功能是正常的，并且域名解析能夠正常工作：
如果網絡功能不正常，ocssd.bin 進程仍然可能被啟動, 但是 crsd.bin 可能會失敗，同時在 crsd.log 中會提示以下信息:
2010-02-03 23:34:28.412: [ GPnP][2235814832]clsgpnp_Init: [at clsgpnp0.c:837] GPnP client pid=867, tl=3, f=0
2010-02-03 23:34:28.428: [ OCRAPI][2235814832]clsu_get_private_ip_addresses: no ip addresses found.
..
2010-02-03 23:34:28.434: [ OCRAPI][2235814832]a_init:13!: Clusterware init unsuccessful : [44]
2010-02-03 23:34:28.434: [ CRSOCR][2235814832] OCR context init failure. Error: PROC-44: Error in network address and interface operations Network address and interface operations error [7]
2010-02-03 23:34:28.434: [ CRSD][2235814832][PANIC] CRSD exiting: Could not init OCR, code: 44
或者:
2009-12-10 06:28:31.974: [ OCRMAS][20]proath_connect_master:1: could not connect to master clsc_ret1 = 9, clsc_ret2 = 9
2009-12-10 06:28:31.974: [ OCRMAS][20]th_master:11: Could not connect to the new master
2009-12-10 06:29:01.450: [ CRSMAIN][2] Policy Engine is not initialized yet!
2009-12-10 06:29:31.489: [ CRSMAIN][2] Policy Engine is not initialized yet!
或者:
2009-12-31 00:42:08.110: [ COMMCRS][10]clsc_receive: (102b03250) Error receiving, ns (12535, 12560), transport (505, 145, 0)
關于網絡和域名解析的驗證，請參考：note 1054902.1
5. crsd 可執行文件(crsd.bin 和 crsd in GRID_HOME/bin) 的權限或者屬主正確并且沒有進行過手工的修改, 一個簡單可行的檢查辦法是對比好的節點和壞節點的以下命令輸出 "ls -l /bin/crsd /bin/crsd.bin".
6. 關于CRSD進程啟動問題的進一步深入診斷，請參考 note 1323698.1 - Troubleshooting CRSD Start up Issue
1.1.6. 問題 5: GPNPD.BIN 無法啟動
1. 網絡的域名解析不正常
gpnpd.bin 進程啟動失敗，以下信息提示在 gpnpd.log 中:
2010-05-13 12:48:11.540: [ GPnP][1171126592]clsgpnpm_exchange: [at clsgpnpm.c:1175] Calling "tcp://node2:9393", try 1 of 3...
2010-05-13 12:48:11.540: [ GPnP][1171126592]clsgpnpm_connect: [at clsgpnpm.c:1015] ENTRY
2010-05-13 12:48:11.541: [ GPnP][1171126592]clsgpnpm_connect: [at clsgpnpm.c:1066] GIPC gipcretFail (1) gipcConnect(tcp-tcp://node2:9393)
2010-05-13 12:48:11.541: [ GPnP][1171126592]clsgpnpm_connect: [at clsgpnpm.c:1067] Result: (48) CLSGPNP_COMM_ERR. Failed to connect to call url "tcp://node2:9393"
以上的例子，請確定當前節點能夠正常的 ping 到“node2” ，并且確認兩個節點之間沒有任何防火墻。
2. bug 10105195
由于 bug 10105195, gpnp 的調度線程（dispatch thread）可能被阻斷，例如：網絡掃描。這個 bug 在 11.2.0.2 GI PSU2，11.2.0.3 及以上版本被修復，具體信息，請參見 note 10105195.8。
1.1.7. 問題 6: 其它的一些守護進程無法啟動
常見原因:
1. 守護進程的日志文件或者日志所在的路徑權限或者屬主不正確。
如果日志文件或者日志文件所在的路徑權限或者屬主設置有問題，通常我們會看到進程嘗試啟動，但是日志里的信息卻始終沒有更新.
關于日志位置和權限屬主的限制，請參見 "日志文件位置, 屬主和權限" 獲取更多的信息。
2. 網絡的 socket 文件權限或者屬主錯誤
這種情況下，守護進程的日志會顯示以下信息:
2010-02-02 12:55:20.485: [ COMMCRS][1121433920]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=rac1DBG_GIPCD))
2010-02-02 12:55:20.485: [ clsdmt][1110944064]Fail to listen to (ADDRESS=(PROTOCOL=ipc)(KEY=rac1DBG_GIPCD))
3. OLR 文件損壞
這種情況下，守護進程的日志會顯示以下信息(以下是個 ora.ctssd 無法啟動的例子):
2012-07-22 00:15:16.565: [ default][1]clsvactversion:4: Retrieving Active Version from local storage.
2012-07-22 00:15:16.575: [ CTSS][1]clsctss_r_av3: Invalid active version [] retrieved from OLR. Returns [19].
2012-07-22 00:15:16.585: [ CTSS][1](:ctss_init16:): Error [19] retrieving active version. Returns [19].
2012-07-22 00:15:16.585: [ CTSS][1]ctss_main: CTSS init failed [19]
2012-07-22 00:15:16.585: [ CTSS][1]ctss_main: CTSS daemon aborting [19].
2012-07-22 00:15:16.585: [ CTSS][1]CTSS daemon aborting
解決辦法，請恢復一個好的OLR的副本，具體辦法請參見 note 1193643.1
1.1.8. 問題 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 等資源
我們可以通過以下命令查看用戶的資源狀態:
$GRID_HOME/crsctl stat res -t
如果 crsd.bin 無法正常啟動以上任何一個 agent，用戶的資源都將無法正常啟動.
1. 通常這些 agent 無法啟動的常見原因是 agent 的日志或者日志所在的路徑沒有設置合適的權限或者屬主。
請參見以下 "日志文件位置, 屬主和權限" 部分關于日志權限的設置。
2. agent 可能因為 bug 11834289 無法啟動，此時我們會看到 "CRS-5802: Unable to start the agent process"錯誤信息，請參見 "OHASD 無法啟動" #10 獲取更多信息。
1.1.9. 問題 8: HAIP 無法啟動
HAIP 無法啟動的原因有很多,例如：
[ohasd(891)]CRS-2807:Resource 'ora.cluster_interconnect.haip' failed to start automatically.
請參見 note?1210883.1 獲取更多關于 HAIP 的信息。
1.1.10. 網絡和域名解析的驗證
CRS 的啟動，依賴于網絡功能和域名解析的正常工作，如果網絡功能或者域名解析不能正常工作，CRS 將無法正常啟動。
關于網絡和域名解析的驗證，請參考： note 1054902.1
1.1.11. 日志文件位置, 屬主和權限
正確的設置 $GRID_HOME/log 和這里的子目錄以及文件對 CRS 組件的正常啟動是至關重要的。
1.1.11.1. 在 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 中是否有一些遞歸的權限和屬主改變，如果您已經有一個相同版本的正在運行的工作節點，您可以把該運行的節點作為參考。
1.1.11.2. 在 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
1.1.12. 網絡socket文件的位置，屬主和權限
網絡的 socket 文件可能位于目錄： /tmp/.oracle, /var/tmp/.oracle or /usr/tmp/.oracle 中。
當網絡的 socket 文件權限或者屬主設置不正確的時候，我們通常會在守護進程的日志中看到以下類似的信息:
2011-06-18 14:07:28.545: [ COMMCRS][772]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=racnode1DBG_EVMD))
2011-06-18 14:07:28.545: [ clsdmt][515]Fail to listen to (ADDRESS=(PROTOCOL=ipc)(KEY=lena042DBG_EVMD))
2011-06-18 14:07:28.545: [ clsdmt][515]Terminating process
2011-06-18 14:07:28.559: [ default][515] EVMD exiting on stop request from clsdms_thdmai
以下錯誤也有可能提示:
CRS-5017: The resource action "ora.evmd start" encountered the following error:
CRS-2674: Start of 'ora.evmd' on 'racnode1' failed
..
解決的辦法：請使用 root 用戶停掉 GI，刪除這些 socket 文件，并重新啟動 GI。
我們假設一個 Grid Infrastructure 環境，節點名為 rac1, CRS 的屬主是 grid，以下是 socket 文件夾(../.oracle)正常的設置情況:
1.1.12.1. 在 Grid Infrastructure cluster 環境中:
以下例子是集群環境中的例子：
drwxrwxrwt 2 root oinstall 4096 Feb 2 21:25 .oracle
./.oracle:
drwxrwxrwt 2 root oinstall 4096 Feb 2 21:25 .
srwxrwx--- 1 grid oinstall 0 Feb 2 18:00 master_diskmon
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 mdnsd
-rw-r--r-- 1 grid oinstall 5 Feb 2 18:00 mdnsd.pid
prw-r--r-- 1 root root 0 Feb 2 13:33 npohasd
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 ora_gipc_GPNPD_rac1
-rw-r--r-- 1 grid oinstall 0 Feb 2 13:34 ora_gipc_GPNPD_rac1_lock
srwxrwxrwx 1 grid oinstall 0 Feb 2 13:39 s#11724.1
srwxrwxrwx 1 grid oinstall 0 Feb 2 13:39 s#11724.2
srwxrwxrwx 1 grid oinstall 0 Feb 2 13:39 s#11735.1
srwxrwxrwx 1 grid oinstall 0 Feb 2 13:39 s#11735.2
srwxrwxrwx 1 grid oinstall 0 Feb 2 13:45 s#12339.1
srwxrwxrwx 1 grid oinstall 0 Feb 2 13:45 s#12339.2
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 s#6275.1
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 s#6275.2
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 s#6276.1
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 s#6276.2
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 s#6278.1
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 s#6278.2
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 sAevm
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 sCevm
srwxrwxrwx 1 root root 0 Feb 2 18:01 sCRSD_IPC_SOCKET_11
srwxrwxrwx 1 root root 0 Feb 2 18:01 sCRSD_UI_SOCKET
srwxrwxrwx 1 root root 0 Feb 2 21:25 srac1DBG_CRSD
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 srac1DBG_CSSD
srwxrwxrwx 1 root root 0 Feb 2 18:00 srac1DBG_CTSSD
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 srac1DBG_EVMD
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 srac1DBG_GIPCD
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 srac1DBG_GPNPD
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 srac1DBG_MDNSD
srwxrwxrwx 1 root root 0 Feb 2 18:00 srac1DBG_OHASD
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 sLISTENER
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 sLISTENER_SCAN2
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:01 sLISTENER_SCAN3
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 sOCSSD_LL_rac1_
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 sOCSSD_LL_rac1_eotcs
-rw-r--r-- 1 grid oinstall 0 Feb 2 18:00 sOCSSD_LL_rac1_eotcs_lock
-rw-r--r-- 1 grid oinstall 0 Feb 2 18:00 sOCSSD_LL_rac1__lock
srwxrwxrwx 1 root root 0 Feb 2 18:00 sOHASD_IPC_SOCKET_11
srwxrwxrwx 1 root root 0 Feb 2 18:00 sOHASD_UI_SOCKET
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 sOracle_CSS_LclLstnr_eotcs_1
-rw-r--r-- 1 grid oinstall 0 Feb 2 18:00 sOracle_CSS_LclLstnr_eotcs_1_lock
srwxrwxrwx 1 root root 0 Feb 2 18:01 sora_crsqs
srwxrwxrwx 1 root root 0 Feb 2 18:00 sprocr_local_conn_0_PROC
srwxrwxrwx 1 root root 0 Feb 2 18:00 sprocr_local_conn_0_PROL
srwxrwxrwx 1 grid oinstall 0 Feb 2 18:00 sSYSTEM.evm.acceptor.auth
1.1.12.2. 在 Oracle Restart 環境中:
以下是 Oracle Restart 環境中的輸出例子:
drwxrwxrwt 2 root oinstall 4096 Feb 2 21:25 .oracle
./.oracle:
srwxrwx--- 1 grid oinstall 0 Aug 1 17:23 master_diskmon
prw-r--r-- 1 grid oinstall 0 Oct 31 2009 npohasd
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 s#14478.1
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 s#14478.2
srwxrwxrwx 1 grid oinstall 0 Jul 14 08:02 s#2266.1
srwxrwxrwx 1 grid oinstall 0 Jul 14 08:02 s#2266.2
srwxrwxrwx 1 grid oinstall 0 Jul 7 10:59 s#2269.1
srwxrwxrwx 1 grid oinstall 0 Jul 7 10:59 s#2269.2
srwxrwxrwx 1 grid oinstall 0 Jul 31 22:10 s#2313.1
srwxrwxrwx 1 grid oinstall 0 Jul 31 22:10 s#2313.2
srwxrwxrwx 1 grid oinstall 0 Jun 29 21:58 s#2851.1
srwxrwxrwx 1 grid oinstall 0 Jun 29 21:58 s#2851.2
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sCRSD_UI_SOCKET
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 srac1DBG_CSSD
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 srac1DBG_OHASD
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sEXTPROC1521
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sOCSSD_LL_rac1_
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sOCSSD_LL_rac1_localhost
-rw-r--r-- 1 grid oinstall 0 Aug 1 17:23 sOCSSD_LL_rac1_localhost_lock
-rw-r--r-- 1 grid oinstall 0 Aug 1 17:23 sOCSSD_LL_rac1__lock
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sOHASD_IPC_SOCKET_11
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sOHASD_UI_SOCKET
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sgrid_CSS_LclLstnr_localhost_1
-rw-r--r-- 1 grid oinstall 0 Aug 1 17:23 sgrid_CSS_LclLstnr_localhost_1_lock
srwxrwxrwx 1 grid oinstall 0 Aug 1 17:23 sprocr_local_conn_0_PROL
1.1.13. 診斷文件收集
如果通過本文沒有找到問題原因，請使用 root 用戶，在所有的節點上執行 $GRID_HOME/bin/diagcollection.sh ，并上傳在當前目錄下生成所有的 .gz 壓縮文件來做進一步診斷。
轉載于:https://www.cnblogs.com/cnmarkao/p/10680299.html
總結
以上是生活随笔為你收集整理的【Oracle】RAC11gR2Grid启动顺序及启动故障诊断思路的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 剑指offer-按之字形顺序打印二叉树
- 下一篇： 数据结构（python语言）目录链接