儲存多路徑故障導致資料庫死掉案例

    這幾天的時間裡，資料庫備受摧殘，首先是6月15號，資料庫伺服器網路卡突然失靈，和外界不能通訊，但是ping自己的ip和迴環都沒問題，重啟網路卡也解決不了，硬體的人用筆記本連伺服器的網線，改成伺服器IP後沒有問題，他們就把責任推的一乾二淨，檢視系統日誌並未發現異常，沒有辦法只好重啟資料庫伺服器，問題是得以解決，但是故障原因一直沒有找到，二是週末客戶的空調出現故障，硬體人員將儲存和伺服器全部關閉，週一（6月18號）來的時候還沒有給電，給電後，資料庫伺服器看不到儲存，和硬體人員研究了小半天，後來重新maping了下問題解決，資料庫可以正常啟動，但是週二（6月19號）早上到辦公室，發現資料庫死掉，檢視日誌是由於ASM的一塊磁碟INPUT/OUPTPUT ERROR，而檢視UDEV繫結的ASM磁碟時發現少了（/asm-disk1和/asm-disk2）2塊磁碟：

[root@dbserver2 ~]# ls /dev/asm-disk*

/dev/asm-disk10  /dev/asm-disk12  /dev/asm-disk14  /dev/asm-disk16  /dev/asm-disk18  /dev/asm-disk2   /dev/asm-disk3  /dev/asm-disk6  /dev/asm-disk8

/dev/asm-disk11  /dev/asm-disk13  /dev/asm-disk15  /dev/asm-disk17  /dev/asm-disk19  /dev/asm-disk20  /dev/asm-disk5  /dev/asm-disk7  /dev/asm-disk9

    用ls /dev/sd*檢視磁碟資訊，發現多了10個磁碟分割槽:

[root@dbserver2 ~]# ls /dev/sd*

/dev/sda   /dev/sda3  /dev/sdb   /dev/sdb3  /dev/sdc   /dev/sdc3  /dev/sdd   /dev/sdd3  /dev/sdg1  /dev/sdg4  /dev/sdk2  /dev/sdk5

/dev/sda1  /dev/sda4  /dev/sdb1  /dev/sdb4  /dev/sdc1  /dev/sdc4  /dev/sdd1  /dev/sdd4  /dev/sdg2  /dev/sdg5  /dev/sdk3

/dev/sda2  /dev/sda5  /dev/sdb2  /dev/sdb5  /dev/sdc2  /dev/sdc5  /dev/sdd2  /dev/sdd5  /dev/sdg3  /dev/sdk1  /dev/sdk4

    但是fdisk -l卻很正常：

[root@dbserver2 ~]# fdisk -l | grep Disk

Disk /dev/cciss/c0d0: 1000.1 GB, 1000148590592 bytes

Disk /dev/cciss/c0d1: 1000.1 GB, 1000148590592 bytes

Disk /dev/sda: 10995.1 GB, 10995116277760 bytes

Disk /dev/sdb: 10995.1 GB, 10995116277760 bytes

Disk /dev/sdc: 10995.1 GB, 10995116277760 bytes

Disk /dev/sdd: 10995.1 GB, 10995116277760 bytes

         這個問題很顯然是儲存的多路複用出了問題，但是硬體人員說fdisk -l沒問題，就不是他們的問題，而我對儲存又不是很瞭解，客戶就更不瞭解了，硬體人員又一次將責任推開，我確信是儲存的問題，但是苦於拿不出有說服性的證據，9點半左右，發現ASM又可以看到全部磁碟，資料庫可正常啟動，但是在11點半左右，資料庫又死掉，報ORA-15025等錯誤：

ORA-15025: could not open disk "/dev/asm-disk4"

ORA-27041: unable to open file

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

Tue Jun 19 10:44:27 2012

ORA-1092 : opitsk aborting process

    這叫我很擔心，萬一資料庫折騰出其他問題就不好辦了，20多T的資料量呢，研究了一會我發現當檢視/proc/scsi/scsi檔案時，我可以看到8塊磁碟，正常是4塊：

[root@dbserver2 ~]# cat /proc/scsi/scsi

Attached devices:

Host: scsi0 Channel: 00 Id: 00 Lun: 00

  Vendor: hp       Model: DVD D  DS8D3SH   Rev: HHE7

  Type:   CD-ROM                           ANSI  SCSI revision: 05

Host: scsi2 Channel: 00 Id: 02 Lun: 00

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

Host: scsi2 Channel: 00 Id: 02 Lun: 01

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

Host: scsi2 Channel: 00 Id: 02 Lun: 02

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

Host: scsi2 Channel: 00 Id: 02 Lun: 03

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

Host: scsi2 Channel: 00 Id: 03 Lun: 00

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

Host: scsi2 Channel: 00 Id: 03 Lun: 01

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

Host: scsi2 Channel: 00 Id: 03 Lun: 02

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

Host: scsi2 Channel: 00 Id: 03 Lun: 03

  Vendor: HITACHI  Model: DF600F           Rev: 0000

  Type:   Direct-Access                    ANSI  SCSI revision: 04

         這回硬體人員承認是儲存多路複用的一條鏈路出了問題，後經硬體人員處理後，問題解決，停了小半天的資料庫又開始正常執行，我想說的是，多家公司一起做一個專案，在出現問題的時候，不要急於推卸責任，應該先找到並解決問題，該是你的責任推也推不掉，雖然客戶並沒有追究這次事故，但是對我工作的耽誤還是蠻大的。