【RAC】儲存陣列電源故障導致RAC資料庫異常掛起
將曾經經歷過的一起RAC故障總結在此，希望引起大家的思考和總結。
1.故障現象
故障現象非常的明顯，無論使用何種手段均無法啟動RAC對應的服務。
在嘗試啟動資料庫例項的過程中alert記錄瞭如下資訊。
Wed Feb 9 09:32:33 2011
This instance was first to mount
Wed Feb 9 09:32:33 2011
ORA-00202: control file: '+ORADATA/racdb/controlfile/current.256.668238016'
ORA-17503: ksfdopn:2 Failed to open file +ORADATA/racdb/controlfile/current.256.668238016
ORA-15001: diskgroup "ORADATA" does not exist or is not mounted
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-205 signalled during: ALTER DATABASE MOUNT...
Wed Feb 9 09:35:13 2011
Reconfiguration started (old inc 2, new inc 4)
List of nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
這裡提示磁碟組ORADATA未掛載成功，無法開啟對應的控制檔案。
2.故障分析
單純從alert日誌之中進行分析，很難直接定位是由於儲存陣列的故障引發的這次資料庫問題。
進一步追溯故障的根源。
1）檢視裸裝置的配置檔案
cat /etc/udev/rules.d/60-raw.rules
# block devices with O_DIRECT.
#
# Enter raw device bindings here.
#
# An example would be:
# ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"
# to bind /dev/raw/raw1 to /dev/sda, or
# ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw2 %M %m"
# to bind /dev/raw/raw2 to the device with major 8, minor 1.
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/sdc2", 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"
2）檢視作業系統中與之對應的裝置資訊
racdb1@racdb1 /dev$ ls -l | grep sd
brw-r----- 1 root disk 8, 0 2011-02-09 sda
brw-r----- 1 root disk 8, 1 02-09 09:26 sda1
brw-r----- 1 root disk 8, 2 02-09 09:26 sda2
brw-r----- 1 root disk 8, 16 2011-02-09 sdb
brw-r----- 1 root disk 8, 17 02-09 09:26 sdb1
brw-r----- 1 root disk 8, 18 02-09 09:26 sdb2
brw-r----- 1 root disk 8, 32 2011-02-09 sdc
brw-r----- 1 root disk 8, 33 02-09 09:26 sdc1
brw-r----- 1 root disk 8, 34 02-09 09:26 sdc2
故障的根本原因浮出水面，此時系統中並未識別到sdd相關裝置！
這裡的sdd相關裝置便是磁碟組ORADATA需要的資源！
3）檢視RAC所需磁碟資訊
[root@racdb2 dev]# /etc/init.d/oracleasm listdisks
[root@racdb2 dev]#
返回結果為空，表明無可用儲存。
3.故障處理
既然定位了故障出處，處理起來也便有的放矢。
最終確認了是由於儲存陣列的電源故障引發的此次問題。
恢復故障後再次檢查裝置資訊
racdb1@racdb1 /dev$ ls -l | grep sd
brw-r----- 1 root disk 8, 0 2011-02-09 sda
brw-r----- 1 root disk 8, 1 02-09 11:22 sda1
brw-r----- 1 root disk 8, 2 02-09 11:22 sda2
brw-r----- 1 root disk 8, 16 2011-02-09 sdb
brw-r----- 1 root disk 8, 17 02-09 11:22 sdb1
brw-r----- 1 root disk 8, 18 02-09 11:22 sdb2
brw-r----- 1 root disk 8, 32 2011-02-09 sdc
brw-r----- 1 root disk 8, 33 02-09 11:22 sdc1
brw-r----- 1 root disk 8, 34 02-09 11:22 sdc2
brw-r----- 1 root disk 8, 48 2011-02-09 sdd
brw-r----- 1 root disk 8, 49 02-09 11:22 sdd1
brw-r----- 1 root disk 8, 64 2011-02-09 sde
brw-r----- 1 root disk 8, 65 02-09 11:22 sde1
brw-r----- 1 root disk 8, 66 02-09 11:22 sde2
brw-r----- 1 root disk 8, 67 02-09 11:22 sde3
可見，儲存上的裝置已一一被識別。
racdb1@racdb1 /dev/raw$ ls -tlr
crw------- 1 oracle oinstall 162, 3 02-09 11:22 raw3
crw------- 1 oracle oinstall 162, 5 02-09 11:22 raw5
crw------- 1 oracle oinstall 162, 1 02-09 11:31 raw1
crw------- 1 oracle oinstall 162, 4 02-09 11:31 raw4
crw------- 1 oracle oinstall 162, 2 02-09 11:31 raw2
故障得到比較圓滿的處理。
4.小結
RAC技術可以說是Oracle在高可用上的佳作和絕技，但是對於RAC的維護需要格外的細心，稍有不慎便會在細枝末節上出現紕漏，後果很嚴重！
謹以此文提醒RAC DBA朋友們：定期全面的健康檢查不是例行公事，而是保障資料庫高效穩定執行的前提！
Good luck.
secooler
11.03.29
-- The End --
1.故障現象
故障現象非常的明顯，無論使用何種手段均無法啟動RAC對應的服務。
在嘗試啟動資料庫例項的過程中alert記錄瞭如下資訊。
Wed Feb 9 09:32:33 2011
This instance was first to mount
Wed Feb 9 09:32:33 2011
ORA-00202: control file: '+ORADATA/racdb/controlfile/current.256.668238016'
ORA-17503: ksfdopn:2 Failed to open file +ORADATA/racdb/controlfile/current.256.668238016
ORA-15001: diskgroup "ORADATA" does not exist or is not mounted
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-205 signalled during: ALTER DATABASE MOUNT...
Wed Feb 9 09:35:13 2011
Reconfiguration started (old inc 2, new inc 4)
List of nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
這裡提示磁碟組ORADATA未掛載成功，無法開啟對應的控制檔案。
2.故障分析
單純從alert日誌之中進行分析，很難直接定位是由於儲存陣列的故障引發的這次資料庫問題。
進一步追溯故障的根源。
1）檢視裸裝置的配置檔案
cat /etc/udev/rules.d/60-raw.rules
# block devices with O_DIRECT.
#
# Enter raw device bindings here.
#
# An example would be:
# ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"
# to bind /dev/raw/raw1 to /dev/sda, or
# ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw2 %M %m"
# to bind /dev/raw/raw2 to the device with major 8, minor 1.
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/sdc2", 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"
2）檢視作業系統中與之對應的裝置資訊
racdb1@racdb1 /dev$ ls -l | grep sd
brw-r----- 1 root disk 8, 0 2011-02-09 sda
brw-r----- 1 root disk 8, 1 02-09 09:26 sda1
brw-r----- 1 root disk 8, 2 02-09 09:26 sda2
brw-r----- 1 root disk 8, 16 2011-02-09 sdb
brw-r----- 1 root disk 8, 17 02-09 09:26 sdb1
brw-r----- 1 root disk 8, 18 02-09 09:26 sdb2
brw-r----- 1 root disk 8, 32 2011-02-09 sdc
brw-r----- 1 root disk 8, 33 02-09 09:26 sdc1
brw-r----- 1 root disk 8, 34 02-09 09:26 sdc2
故障的根本原因浮出水面，此時系統中並未識別到sdd相關裝置！
這裡的sdd相關裝置便是磁碟組ORADATA需要的資源！
3）檢視RAC所需磁碟資訊
[root@racdb2 dev]# /etc/init.d/oracleasm listdisks
[root@racdb2 dev]#
返回結果為空，表明無可用儲存。
3.故障處理
既然定位了故障出處，處理起來也便有的放矢。
最終確認了是由於儲存陣列的電源故障引發的此次問題。
恢復故障後再次檢查裝置資訊
racdb1@racdb1 /dev$ ls -l | grep sd
brw-r----- 1 root disk 8, 0 2011-02-09 sda
brw-r----- 1 root disk 8, 1 02-09 11:22 sda1
brw-r----- 1 root disk 8, 2 02-09 11:22 sda2
brw-r----- 1 root disk 8, 16 2011-02-09 sdb
brw-r----- 1 root disk 8, 17 02-09 11:22 sdb1
brw-r----- 1 root disk 8, 18 02-09 11:22 sdb2
brw-r----- 1 root disk 8, 32 2011-02-09 sdc
brw-r----- 1 root disk 8, 33 02-09 11:22 sdc1
brw-r----- 1 root disk 8, 34 02-09 11:22 sdc2
brw-r----- 1 root disk 8, 48 2011-02-09 sdd
brw-r----- 1 root disk 8, 49 02-09 11:22 sdd1
brw-r----- 1 root disk 8, 64 2011-02-09 sde
brw-r----- 1 root disk 8, 65 02-09 11:22 sde1
brw-r----- 1 root disk 8, 66 02-09 11:22 sde2
brw-r----- 1 root disk 8, 67 02-09 11:22 sde3
可見，儲存上的裝置已一一被識別。
racdb1@racdb1 /dev/raw$ ls -tlr
crw------- 1 oracle oinstall 162, 3 02-09 11:22 raw3
crw------- 1 oracle oinstall 162, 5 02-09 11:22 raw5
crw------- 1 oracle oinstall 162, 1 02-09 11:31 raw1
crw------- 1 oracle oinstall 162, 4 02-09 11:31 raw4
crw------- 1 oracle oinstall 162, 2 02-09 11:31 raw2
故障得到比較圓滿的處理。
4.小結
RAC技術可以說是Oracle在高可用上的佳作和絕技，但是對於RAC的維護需要格外的細心，稍有不慎便會在細枝末節上出現紕漏，後果很嚴重！
謹以此文提醒RAC DBA朋友們：定期全面的健康檢查不是例行公事，而是保障資料庫高效穩定執行的前提！
Good luck.
secooler
11.03.29
-- The End --
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/519536/viewspace-691262/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【RAC】處理因ASM例項異常導致RAC第一節點例項異常終止故障ASM
- 記一次儲存問題導致的rac故障案例
- 儲存多路徑故障導致資料庫死掉案例資料庫
- Oracle RAC啟動因CTSS導致的異常Oracle
- 歸檔日誌滿導致的資料庫掛起故障處理資料庫
- ASM磁碟組故障導致資料庫不能起來ASM資料庫
- 【故障處理】多陣列掛接使裝置名稱混亂導致RAC無法啟動問題陣列
- 歸檔日誌滿導致的資料庫掛起故障處理【轉載】資料庫
- sql server資料庫如何儲存陣列，int[]float[]double[]陣列儲存到資料庫方法SQLServer資料庫陣列
- ASM空間爆滿導致資料庫掛起ASM資料庫
- RAC因為localhost磁碟空間不夠導致has程式掛起localhost
- 異常程式導致大量資源佔用
- 【伺服器資料恢復】異常斷電導致ESXI無法連線儲存的資料恢復案例伺服器資料恢復
- HA異常導致oracle資料庫無法啟動Oracle資料庫
- SCN異常增長導致資料庫異常關閉風險的防範資料庫
- 處理rac資料庫一個節點監聽異常資料庫
- 【伺服器資料恢復】斷電導致儲存raid6陣列癱瘓的資料恢復案例伺服器資料恢復AI陣列
- Oracle 資料庫不一致導致異常的恢復Oracle資料庫
- 3節點RAC資料庫夯故障分析資料庫
- Oracle RAC日常運維-NetworkManager導致叢集故障Oracle運維
- oracle 11.2.0.3 rac資料庫線上新增ASM儲存空間Oracle資料庫ASM
- oracle RAC 更換儲存遷移資料Oracle
- RAC資料庫一節點更換HBA卡導致emc儲存裝置序號變動處理記錄資料庫
- 【北亞伺服器資料恢復】異常斷電導致ESXI系統無法連線儲存的資料恢復伺服器資料恢復
- 【北亞資料恢復】異常斷電導致Oracle資料庫報錯的oracle資料恢復資料恢復Oracle資料庫
- 資料庫連線異常故障報告資料庫
- 記 Laravel Observer 導致 Redis 佇列異常LaravelServerRedis佇列
- 【故障處理】DBCA建庫詭異問題處理--rac環境不能建立rac庫
- GDI資源洩漏導致的程式異常的解析
- Oracle 10g RAC 資料儲存更換Oracle 10g
- 【伺服器資料恢復】raid5故障導致儲存的卷無法掛載的資料恢復伺服器資料恢復AI
- OEL 11.2.0.2 RAC 資料庫停電導致has程式無法啟動OLR檔案損壞資料庫
- nas儲存伺服器硬碟故障離線導致的磁碟陣列失效、伺服器無法訪問的資料恢復案例伺服器硬碟陣列資料恢復
- oracle 11g rac 共享儲存壞掉後資料庫恢復Oracle資料庫
- EVA4400儲存斷電導致資料丟失如何恢復
- 一次GI補丁安裝不完整導致的RAC心跳流量異常
- ORACLE 11.2.0.4 rac for linux 鏈路宕導致的單節點異常當機OracleLinux
- 【伺服器資料恢復】IBM儲存raid5故障導致卷無法掛載的資料恢復伺服器資料恢復IBMAI