客户系统数据库意外关闭了，查看数据库故障时间的警告日志:

发现在故障时间，数据库的警告日志中出现了大量的IO错误，最终导致数据库的核心进程出现错误，导致数据库意外关闭。

既然出现了IO错误，我们肯定需要关注下操作系统的日志：

这里截取其中的几行我们分析下：

Jan 8 14:29:55 zrdb-1 kernel: qla2xxx 0000:18:00.0: LOOP DOWN detected (2).

Jan 8 14:29:55 zrdb-1 kernel: qla2xxx 0000:18:00.0: LOOP DOWN detected (2 5 0).

Jan 8 14:29:56 zrdb-1 kernel: bnx2: eth0 NIC Copper Link is Down

Jan 8 14:29:56 zrdb-1 kernel: eth2: Link is Down

Jan 8 14:29:56 zrdb-1 kernel: bonding: bond1: link status definitely down for interface eth2, disabling it

Jan 8 14:29:56 zrdb-1 kernel: bonding: bond1: making interface eth3 the new active one.

Jan 8 14:29:56 zrdb-1 kernel: bonding: bond0: link status definitely down for interface eth0, disabling it

Jan 8 14:29:56 zrdb-1 kernel: bonding: bond0: making interface eth1 the new active one.

Jan 8 14:30:25 zrdb-1 kernel: port-3:0-1: blocked FC remote port time out: saving binding

Jan 8 14:30:25 zrdb-1 kernel: sd 3:0:0:0: SCSI error: return code = 0x00010000

Jan 8 14:30:25 zrdb-1 kernel: end_request: I/O error, dev sdb, sector 1662453767

Jan 8 14:30:25 zrdb-1 kernel: Buffer I/O error on device sdb1, logical block 207806713

Jan 8 14:30:25 zrdb-1 kernel: lost page write due to I/O error on sdb1

Jan 8 14:30:25 zrdb-1 kernel: Buffer I/O error on device sdb1, logical block 207806714

Jan 8 14:30:25 zrdb-1 kernel: lost page write due to I/O error on sdb1

。。。

Jan 8 14:30:28 zrdb-1 kernel: Aborting journal on device sdb1.

Jan 8 14:30:28 zrdb-1 kernel: sd 3:0:0:0: SCSI error: return code = 0x00010000

Jan 8 14:30:29 zrdb-1 kernel: end_request: I/O error, dev sdb, sector 1981510079

Jan 8 14:30:30 zrdb-1 kernel: ext3_abort called.

Jan 8 14:30:31 zrdb-1 kernel: EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted journal

Jan 8 14:30:34 zrdb-1 kernel: Remounting filesystem read-only --这里文件置为了只读状态

。。。

同样在数据库故障时间段内，操作系统的日志中也报出了大量的IO 错误，然后文件系统出于对磁盘数据的保护，把所在的分区置为只读状态了，从而导致了数据库意外关闭。

不过需要注意的是在报出IO错误之前，网卡down掉了，而且fc的连接也断开过一次，而查看fc存储的日志，发现这个时间段也存在一次意外的中断。

所以推断这一故障的原因很可能是因为网络和fc中断后，导致了fc存储对应的文件系统读取出现了较多的IO错误，而操作系统处于安全考虑将该分区重新置为只读状态，而数据库的核心进程dbwn和lgwr进程由于无法完成写入动作，最终强制将数据库关闭。

此时的解决办法其实很简单的，需要重新把上述所在的磁盘分区重新挂载为可读写状态，然后重新启动数据库。

关于文件系统只读，小鱼以前也遇到了很多次，只是每次小鱼都是直接重新挂载就好了，没去过多分析为什么出现文件系统只读，今天借助这个故障的分析，让我们维护人员应该更多的去了解操作系统、存储和网络，这个虽然不一定是我们所擅长，但是一些基本的我们还是必须去掌握，当然这跟实际的工作环境相关。

Good luck！