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

streamsong發表於2013-01-21

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

[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

    這叫我很擔心,萬一資料庫折騰出其他問題就不好辦了,20T的資料量呢,研究了一會我發現當檢視/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

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26547977/viewspace-752997/,如需轉載,請註明出處,否則將追究法律責任。

相關文章