存储多路径故障导致数据库死掉案例

这几天的时间里，数据库备受摧残，首先是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

        这回硬件人员承认是存储多路复用的一条链路出了问题，后经硬件人员处理后，问题解决，停了小半天的数据库又开始正常运行，我想说的是，多家公司一起做一个项目，在出现问题的时候，不要急于推卸责任，应该先找到并解决问题，该是你的责任推也推不掉，虽然客户并没有追究这次事故，但是对我工作的耽误还是蛮大的。