当前位置: 首页 > Oracle, oracle 10g, oracle 11g > 正文

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

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

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

本文固定链接: http://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/ | 信春哥,系统稳,闭眼上线不回滚!

该日志由 dbdream 于2012年06月24日发表在 Oracle, oracle 10g, oracle 11g 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 存储故障导致数据库死掉案例 | 信春哥,系统稳,闭眼上线不回滚!
关键字: , ,

存储故障导致数据库死掉案例:等您坐沙发呢!

发表评论

您必须 [ 登录 ] 才能发表留言!