【故障處理】多陣列掛接使裝置名稱混亂導致RAC無法啟動問題
今天遭遇RAC資料庫伺服器由於主機硬體問題導致重啟，但伺服器重啟之後RAC資料庫無法啟動。
經分析，導致RAC任何一個節點都無法啟動的原因是無法找到ocr導致crs無法正常提供服務。那因何ocr無故消失？
1.以下是採集到的相關故障日誌
1）例項日誌資訊
Sun Aug 29 15:22:19 2010
Error: KGXGN aborts the instance (6)
Sun Aug 29 15:22:19 2010
Errors in file /oracle/app/oracle/admin/secrac/bdump/secrac2_lmon_21008.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON: terminating instance due to error 29702
2）ASM日誌資訊
ri Jul 9 13:05:10 2010
LMS 0: 5446 GCS shadows traversed, 0 replayed
Fri Jul 9 13:05:10 2010
Submitted all GCS remote-cache requests
Post SMON to start 1st pass IR
Fix write in gcs resources
Reconfiguration complete
Sun Aug 29 15:22:19 2010
Error: KGXGN aborts the instance (6)
Sun Aug 29 15:22:19 2010
Errors in file /oracle/app/oracle/admin/+ASM/bdump/+asm2_lmon_20702.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON: terminating instance due to error 29702
3）crs日誌資訊
cat /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/alertsecrac2.log
2009-05-01 16:05:45.637
[crsd(5597)]CRS-1201:CRSD started on node secrac2.
2009-05-01 16:06:55.369
[cssd(6171)]CRS-1601:CSSD Reconfiguration complete. Active nodes are secrac1 secrac2 .
2010-08-29 15:21:37.028
[cssd(6171)]CRS-1606:CSSD Insufficient voting files available [0 of 1]. Details in /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/cssd/ocssd.log.
4）ocssd.log日誌資訊內容
cat /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/cssd/ocssd.log
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15a59c00 00 00 00 - ...
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: clssscctx->nmctx->nmnode[002]->nodeData: dump of 0x0x15dfe510, len 61
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15dfe510 28 41 44 44 52 45 53 53 - 3d 28 50 52 4f 54 4f 43 (ADDRESS=(PROTOC
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15dfe520 4f 4c 3d 74 63 70 29 28 - 44 45 56 3d 31 38 29 28 L=tcp)(DEV=18)(
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15dfe530 48 4f 53 54 3d 31 30 2e - 31 30 2e 31 30 2e 32 29 HOST=10.10.10.8)
[ CSSD]2010-08-29 15:21:37.119 [1126189376] >TRACE: 0x0x15dfe540 28 50 4f 52 54 3d 32 31 - 31 34 38 29 29 (PORT=21148))
[ CSSD]2010-08-29 15:21:37.119 [1126189376] >TRACE: clssscctx->nmctx->nmnode[002]->con: dump of 0x(nil), len 168
[ CSSD]--- DUMP GROCK STATE DB ---
[ CSSD]----------
[ CSSD] type 2, Id 3, Name = (crs_version)
[ CSSD] flags: 0x0
[ CSSD] grant: count=0, type 0, wait 0
[ CSSD] Member Count =2, master 0
[ CSSD] . . . . .
[ CSSD] memberNo =0, seq 0
[ CSSD] flags = 0x0, granted 0
這些日誌沒有明顯的說明故障原因。
2.繼續挖掘問題原因
因為系統的crs無法啟動，而且在關閉crs的過程中提示無法定位ocr檔案。在檢查裸裝置資訊的時候驚奇的發現ocr對應的raw1裝置不翼而飛。
secrac1@secrac1 /home/oracle$ ls -l /dev/raw/*
crw------- 1 oracle oinstall 162, 2 08-29 10:14 /dev/raw/raw2
crw------- 1 oracle oinstall 162, 3 08-29 11:48 /dev/raw/raw3
crw------- 1 oracle oinstall 162, 4 08-29 10:14 /dev/raw/raw4
crw------- 1 oracle oinstall 162, 5 08-29 11:48 /dev/raw/raw5
3.問題原因浮出水面
在發現raw1不見之後，進而使用fdisk檢視系統磁碟資訊。此時，系統識別到的儲存裝置是從sdb開始編號的，原來的sda被其他裝置搶佔。因為Redhat 5.1作業系統下部署的RAC，裸裝置是透過/etc/udev/rules.d/60-raw.rules檔案進行指定的，因此sda的消失直接導致的結果就是raw1裸裝置不可用，進而ocr資料無法訪問，資料庫當然無論從哪一個節點啟動都無法成功。
# cat /etc/udev/rules.d/60-raw.rules
ACTION=="add", KERNEL=="/dev/sda1", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw1 %M %m"
ACTION=="add", KERNEL=="/dev/sdb1", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="17", RUN+="/bin/raw /dev/raw/raw2 %M %m"
ACTION=="add", KERNEL=="/dev/sdc1", RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="33", RUN+="/bin/raw /dev/raw/raw3 %M %m"
ACTION=="add", KERNEL=="/dev/sdd1", RUN+="/bin/raw /dev/raw/raw4 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="49", RUN+="/bin/raw /dev/raw/raw4 %M %m"
ACTION=="add", KERNEL=="/dev/sde1", RUN+="/bin/raw /dev/raw/raw5 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="34", RUN+="/bin/raw /dev/raw/raw5 %M %m"
KERNEL=="raw1", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw2", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw3", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw4", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw5", WNER="oracle", GROUP="oinstall", MODE="0600"
4.導致裝置名稱混亂的原因
與RAC資料庫伺服器掛載的光纖交換機上存在兩套儲存裝置，就是那套與資料庫無關的儲存裝置導致這起故障的發生。
裝置名稱的識別過程是在作業系統啟動過程中自動完成的，這個應該與Redhat系統kernal有關。
5.小結
從這個案例中總結的的經驗和教訓：
1）有效的備份重於一切，有“備”無患，恢復只是時間的問題；
2）收到故障報警時需要第一時間介入排查；
3）一套有效可行的DRP會錦上添花。
Good luck.
secooler
10.08.30
-- The End --
經分析，導致RAC任何一個節點都無法啟動的原因是無法找到ocr導致crs無法正常提供服務。那因何ocr無故消失？
1.以下是採集到的相關故障日誌
1）例項日誌資訊
Sun Aug 29 15:22:19 2010
Error: KGXGN aborts the instance (6)
Sun Aug 29 15:22:19 2010
Errors in file /oracle/app/oracle/admin/secrac/bdump/secrac2_lmon_21008.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON: terminating instance due to error 29702
2）ASM日誌資訊
ri Jul 9 13:05:10 2010
LMS 0: 5446 GCS shadows traversed, 0 replayed
Fri Jul 9 13:05:10 2010
Submitted all GCS remote-cache requests
Post SMON to start 1st pass IR
Fix write in gcs resources
Reconfiguration complete
Sun Aug 29 15:22:19 2010
Error: KGXGN aborts the instance (6)
Sun Aug 29 15:22:19 2010
Errors in file /oracle/app/oracle/admin/+ASM/bdump/+asm2_lmon_20702.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON: terminating instance due to error 29702
3）crs日誌資訊
cat /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/alertsecrac2.log
2009-05-01 16:05:45.637
[crsd(5597)]CRS-1201:CRSD started on node secrac2.
2009-05-01 16:06:55.369
[cssd(6171)]CRS-1601:CSSD Reconfiguration complete. Active nodes are secrac1 secrac2 .
2010-08-29 15:21:37.028
[cssd(6171)]CRS-1606:CSSD Insufficient voting files available [0 of 1]. Details in /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/cssd/ocssd.log.
4）ocssd.log日誌資訊內容
cat /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/cssd/ocssd.log
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15a59c00 00 00 00 - ...
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: clssscctx->nmctx->nmnode[002]->nodeData: dump of 0x0x15dfe510, len 61
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15dfe510 28 41 44 44 52 45 53 53 - 3d 28 50 52 4f 54 4f 43 (ADDRESS=(PROTOC
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15dfe520 4f 4c 3d 74 63 70 29 28 - 44 45 56 3d 31 38 29 28 L=tcp)(DEV=18)(
[ CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE: 0x0x15dfe530 48 4f 53 54 3d 31 30 2e - 31 30 2e 31 30 2e 32 29 HOST=10.10.10.8)
[ CSSD]2010-08-29 15:21:37.119 [1126189376] >TRACE: 0x0x15dfe540 28 50 4f 52 54 3d 32 31 - 31 34 38 29 29 (PORT=21148))
[ CSSD]2010-08-29 15:21:37.119 [1126189376] >TRACE: clssscctx->nmctx->nmnode[002]->con: dump of 0x(nil), len 168
[ CSSD]--- DUMP GROCK STATE DB ---
[ CSSD]----------
[ CSSD] type 2, Id 3, Name = (crs_version)
[ CSSD] flags: 0x0
[ CSSD] grant: count=0, type 0, wait 0
[ CSSD] Member Count =2, master 0
[ CSSD] . . . . .
[ CSSD] memberNo =0, seq 0
[ CSSD] flags = 0x0, granted 0
這些日誌沒有明顯的說明故障原因。
2.繼續挖掘問題原因
因為系統的crs無法啟動，而且在關閉crs的過程中提示無法定位ocr檔案。在檢查裸裝置資訊的時候驚奇的發現ocr對應的raw1裝置不翼而飛。
secrac1@secrac1 /home/oracle$ ls -l /dev/raw/*
crw------- 1 oracle oinstall 162, 2 08-29 10:14 /dev/raw/raw2
crw------- 1 oracle oinstall 162, 3 08-29 11:48 /dev/raw/raw3
crw------- 1 oracle oinstall 162, 4 08-29 10:14 /dev/raw/raw4
crw------- 1 oracle oinstall 162, 5 08-29 11:48 /dev/raw/raw5
3.問題原因浮出水面
在發現raw1不見之後，進而使用fdisk檢視系統磁碟資訊。此時，系統識別到的儲存裝置是從sdb開始編號的，原來的sda被其他裝置搶佔。因為Redhat 5.1作業系統下部署的RAC，裸裝置是透過/etc/udev/rules.d/60-raw.rules檔案進行指定的，因此sda的消失直接導致的結果就是raw1裸裝置不可用，進而ocr資料無法訪問，資料庫當然無論從哪一個節點啟動都無法成功。
# cat /etc/udev/rules.d/60-raw.rules
ACTION=="add", KERNEL=="/dev/sda1", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw1 %M %m"
ACTION=="add", KERNEL=="/dev/sdb1", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="17", RUN+="/bin/raw /dev/raw/raw2 %M %m"
ACTION=="add", KERNEL=="/dev/sdc1", RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="33", RUN+="/bin/raw /dev/raw/raw3 %M %m"
ACTION=="add", KERNEL=="/dev/sdd1", RUN+="/bin/raw /dev/raw/raw4 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="49", RUN+="/bin/raw /dev/raw/raw4 %M %m"
ACTION=="add", KERNEL=="/dev/sde1", RUN+="/bin/raw /dev/raw/raw5 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="34", RUN+="/bin/raw /dev/raw/raw5 %M %m"
KERNEL=="raw1", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw2", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw3", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw4", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw5", WNER="oracle", GROUP="oinstall", MODE="0600"
4.導致裝置名稱混亂的原因
與RAC資料庫伺服器掛載的光纖交換機上存在兩套儲存裝置，就是那套與資料庫無關的儲存裝置導致這起故障的發生。
裝置名稱的識別過程是在作業系統啟動過程中自動完成的，這個應該與Redhat系統kernal有關。
5.小結
從這個案例中總結的的經驗和教訓：
1）有效的備份重於一切，有“備”無患，恢復只是時間的問題；
2）收到故障報警時需要第一時間介入排查；
3）一套有效可行的DRP會錦上添花。
Good luck.
secooler
10.08.30
-- The End --
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/519536/viewspace-672242/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【故障處理】修改主機名導致oracle例項無法啟動暨如何修改hostnameOracle
- 【問題處理】因ASM磁碟組空間不足導致資料庫例項無法啟動的故障處理ASM資料庫
- 應用使用JNDI，資料庫無法連線，導致的程序無法啟動問題處理資料庫
- 【RAC】儲存陣列電源故障導致RAC資料庫異常掛起陣列資料庫
- 【LISTENER】謹防相同的 IPC key導致多監聽無法啟動--TNS-1106故障處理
- 解決hyper v導致docker無法啟動問題Docker
- 【問題處理】因誤修改inittab檔案導致Oracle 10gR2 CRS無法啟動Oracle 10g
- 私拉亂接導致網路印表機故障
- 歸檔問題導致的資料庫無法啟動資料庫
- 【故障處理】RAC環境第二節點無法歸檔的詭異問題處理
- 【問題處理】恢復因誤生成PFILE 導致RAC的SPFILE無效的問題
- 【RAC】處理VIP資源被佔用導致Cluster叢集軟體無法正常部署問題
- jdk版本導致tomcat,eclipse無法啟動的問題JDKTomcatEclipse
- oracle兩節點RAC，由於gipc導致某節點crs無法啟動問題分析Oracle
- Oracle日常問題處理-資料庫無法啟動Oracle資料庫
- Windows 下處理資料庫無法啟動問題Windows資料庫
- /dev/bpf裝置缺失導致RAC安裝時HAIP啟動失敗devAI
- sqlldr標準輸出未處理導致批處理掛起問題SQL
- 【故障處理】【oerr】【grep】謹防grep“花哨”功能導致oerr工具無法使用
- idea外掛報錯導致不能啟動的處理技巧Idea
- 關於RAC共享儲存兩個節點磁碟裝置名稱不一致的問題
- 【故障處理】使用GC調整資料庫為SGA自動管理後導致例項無法啟動（ORA-00824）GC資料庫
- Workstation服務無法啟動導致無法訪問檔案伺服器伺服器
- Linux下共享庫問題導致無法啟動SQLPLUS的問題解決LinuxSQL
- Windows最佳化大師最佳化後導致監聽無法啟動處理辦法Windows
- docker容器故障致無法啟動解決例項Docker
- 【RAC】處理因ons導致CPU使用率過高的問題
- 懷疑私網網路卡多播問題導致crs無法正常啟動
- 記一次儲存問題導致的rac故障案例
- terminating the instance due to error481導致ASM無法啟動故障ErrorASM
- 修改計算機名後導致Oracle無法訪問的問題修復計算機Oracle
- 【故障處理】DBCA建庫詭異問題處理--rac環境不能建立rac庫
- Electron安裝過程深入解析（讀完此文解決Electron安裝失敗導致的無法啟動，無法打包的問題）
- start_udev導致監聽自動停止問題處理dev
- memory_target設定不當導致資料庫無法啟動的問題資料庫
- 歸檔日誌滿導致的資料庫掛起故障處理資料庫
- docker容器故障致無法啟動解決例項薦Docker
- 字元顯示亂碼問題處理辦法字元