一次Oracle 10g RAC 非正常DOWN後,CRS起不來一次解決過程

PRD系統..幫朋友解決的..

寫的有點亂,我自己能看明白..呵呵方便再用的查詢

[@more@]

環境:
RedHat Linux ent4 +Oracle 10g RAC(10.2.0.1)+ASM

故障現象:
- 在沒有正常關閉Oracle 資料庫的任何元件的情況下,reboot機器.
- Reboot後,CRS起不來.

解決過程:
- 聽取故障產生的過程
- 登陸到系統到系統中
ps -ef | grep crs /evm/css
發現只有/etc/ini.d下的自動啟動守侯程式啟動
ps -ef |grep d.bin
無任何程式,說明CRS沒有啟動
- 切換到root 使用者./opt/oracle/product/10g/crs/bin/crsctl start crs
再次ps -ef | grep d.bin

- 確認兩臺機器的網路等效性
root/oracle 使用者都測試一下,發現root不可以,rsh TEST2 ls .
把SERVER REBOOT
root/oracle 使用者下,.rhost 裡都加上相互的TEST2-priv root/oracle TEST2-vip root/oracle ,並賦予755許可權
最後等效性成功
發現有短暫的程式起來後,但馬上就沒有
- 檢視CRS日誌,發現自從SERVER REBOOT後,沒有任何的CRS日誌,同時也沒有
但發現如下的日誌:
2008-07-26 18:26:25.610: [ OCRCONF][3086862016]ocrconfig starts...
2008-07-26 18:26:27.276: [ OCRCONF][3086862016]Failure initializing ocr in DEFAULT. REBOOT INSTALL. err :[PROC-32: Cluster Ready Services on the local node is not running Messaging error [9]]
2008-07-26 18:26:27.289: [ OCRRAW][3086862016]propriogid:1: INVALID FORMAT
2008-07-26 18:26:27.289: [ OCRRAW][3086862016]proprioini: disk 0 (/dev/raw/raw1) doesn't have enough votes (1,2)
2008-07-26 18:26:27.290: [ OCRRAW][3086862016]proprinit: Could not open raw device
2008-07-26 18:26:27.290: [ default][3086862016]a_init:7!: Backend init unsuccessful : [26]
2008-07-26 18:26:27.290: [ OCRCONF][3086862016]Failure in initializing ocr in INSTALL level. error:[PROC-26: Error while accessing the physical storage]
2008-07-26 18:26:27.290: [ OCRCONF][3086862016]Exiting [status=failed]...
- crsctl query css votedisk
發現沒資料出來
- ocrcheck 沒資料出來

現在已經判定是由於RAW的找不到造成的原因了
-/sbin/ifconfig
檢視網路沒問題
/etc/sysconfig/rawdevices 2個節點上
檢視對應的RAW
chmod 777 所有CRS/VOTING 相關的RAW都改變許可權
- service rawdevices restart(service cluster start) 2個節點上
顯示都正常

- sbin/cluconfig(配置CLUSTER的命令)(沒用到)
- /sbin/fdisk -l 檢視disk 2個節點上都看,顯示正常

- 讓作業系統的管理的
dd 實驗一下,是否那些RAW是可以用的,回答是可以用的
兩邊都可以,所以,RAW是可以用的

現在可以基本判定是CRS的配置檔案壞了

- 讓他們恢復昨天晚上8點的備份過來
採用DD的方式.
- 再次去檢視對應的RAW的檔案屬性,是否是DBA屬組..把許可權許可權改成777
- crsctl query css votedisk
出現對應的RAW裝置了
- ocrcheck 有正常顯示

- ps -ef |grep d.bin
相關的程式起來了

- ps -ef | grep tns
監聽起來了

- ps -ef | grep ora_
資料庫程式起來了

說明TEST1沒任何問題了

現在可以去檢查第2個節點了

同樣都起來了

至此,問題得到完全的解決~

總結:
- 要按正常的流程起停資料庫
- LINUX的東西還真不穩定
- 系統本身有問題,安裝的時候可能就不完善
- 沒打任何補丁,沒任何安全保障
- 業務需要沒必要用那麼複雜的配置,維護成本太高
- 沒有任何規劃,問題多多