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

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

本文固定链接: https://www.dbdream.com.cn/2012/06/%e5%ad%98%e5%82%a8%e6%95%85%e9%9a%9c%e5%af%bc%e8%87%b4%e6%95%b0%e6%8d%ae%e5%ba%93%e6%ad%bb%e6%8e%89%e6%a1%88%e4%be%8b/ | 信春哥，系统稳，闭眼上线不回滚！