从一次失败的故障处理中能学到些什么？

这是老白数年前遇到的一个案例，里面遇到了几乎所有的运维人员在故障处置时能够犯到的错误。今天看到这个材料，想写出来和大家分享。

这是一个十分典型的故障，十分典型的故障处置过程，最后的后果很严重，最终又不是那么严重。

实际上老白是在去客户现场前就知道这个故障的一些情况的。据说当时客户的DSG突然宕了，现场运维人员努力重启了多次，但是没有成功。因为这是一个两节点的RAC系统，所以现场运维人员也们没有仔细分析故障原因，采用了重启大法。没想到这个百试百灵的大法这回不灵了，不光是不灵了，甚至重启后HACMP都无法把一个数据库所需的卷组拉起来了。于是数据库就无法启动了。这个时间是晚上的22：30分。

》》》老白点评：没有仔细检查问题原因，就确定采用重启来解决问题是绝大多数运维人员都做过的事情，实际上这种操作是十分危险的。一旦出现问题，系统没有恢复，可能会带来更大的问题。这个案例就是一个例证。

运维人员努力修复故障节点，不过并未成功，于是在早上6点半左右，艰苦奋战了一晚上的运维人员突然想到一个妙招，再重启另外一个节点，看看能不能恢复系统。于是另外一台服务器也被重启了。重启完成后，一个更为严峻的情况摆在了大家面前，另外一个节点的HACMP也无法挂在某个卷组。数据库中有200多个文件处于故障状态，数据库无法启动。这下完蛋了，所有两个节点全部故障，整个数据库处于无法使用的状态。

》》》老白点评：当前的状态是单节点运行，还是可以接受的，这时候，水平与能力不足的现场运维人员就不应该继续自己瞎折腾了。马上寻求专家支持是十分必要的。早上6点半，忙了一晚，脑袋发晕的人就不应该做重大决策了。而且6点半离营业厅开业的8：30只有两小时时间，做重大操作一旦出现问题就是万劫不复。

在这种状态下，早上7点多，现场运维人员与开发商取得了联系，并由开发商的DBA指导开展恢复工作，经过远程分析，开发商的DBA认为系统已无法恢复，需要立即启用RMAN恢复操作。于是在10点30左右，开始做RMAN恢复。幸运的是，这套系统在前一天晚上做了一个全备，而且是成功的。恢复进行了几个小时后，大家觉得文件恢复的似乎有点慢，于是推算了一下，按照当前速度，13TB的数据恢复大约需要28个小时。这套系统是企业最关键的业务系统，停机超过8小时就算严重事故，停机超过24小时相关责任人要受到处分。于是现场运维人员才意识到问题的严重性，开始寻找专家进行协助。等老白拿到现场的日志的时候，感觉好像是AIX系统的一个VG出现了问题，于是让用户把vg的ODM数据采集回来分析。通过ODM数据的分析，发现这个VG丢失了一块盘。于是让用户把这个VG的所有盘的磁盘头DUMP出来看看。

这个PV中一共有三个PV，其中一个PV的VGDA数据区是空的：

下面是一个正确的VGDA数据，来自于另外一块盘。

经过分析，发现是VGDA坏了，那么实际上处置起来还比较简单，通过odm命令可以把这个设备的VGDA区域数据修复好，这样这块盘就可以恢复了。于是老白把命令准备好，让现场人员抓紧恢复。很快这个VG就修复好了。老白正在为即将到来的胜利欢呼的时候，一个更为严峻的问题出现了。用户RMAN恢复已经将另外两个好的VG中的多个数据文件覆盖了。此时哪怕这些文件可以恢复，其他很多数据文件也已经被覆盖了。这次成功的VGDA修复变得毫无意义了。

于是一切恢复到从前，大家只能等待恢复的结束。又过了二十多个小时，数据文件恢复结束，然后开始恢复归档日志，做介质恢复。后来大家再也没有犯错误，甚至现场运维人员还考虑到了REDO LOG在另外一个VG上，都没有损坏，于是把REDO LOG恢复回来，数据一条都没丢。不过最终完成恢复的时间是38个小时，此时离系统宕机已经接近48小时了。后来老白到现场后进行了更仔细的复盘，实际上发现这个系统在故障前1天左右就已经出现了故障迹象，只是由于现场的监控手段不足，导致问题没有被运维人员发现，在系统故障之后，运维人员也没有认真检查日志报错，从而错过了准确定位故障的时机，采取了放大故障的措施，最终导致这个灾难。早在早上的6点多，DSG使用的文件系统中的Oracle trace就出现了大量的字节数为0的文件，而从监控数据看，文件系统并没有满。

从errpt也可以看到scsi链路也出现过故障。

如果监控到位，同时运维人员在故障发生后能够认真检查系统日志，则这个问题是应该可以被发现的。如果存储系统存在问题，那么运维人员就不一定敢重启服务器了。可惜当时做这个工作的人是个对操作系统不太熟悉的DBA，甚至连errpt都不太会看。但是他做出了一个十分大胆的动作，重启了服务器。

在做故障处置的时候，让相关专家尽早介入，并尽在专家分析清楚问题原因之前，尽可能少做有风险的操作，对于问题的正确解决，是至关重要的。