近日，恩墨科技帮助用户恢复了严重的ASM存储故障，帮助用户在1个小时之内快速恢复服务，经过不断的技术探索和研究，恩墨科技已经具备了帮助用户恢复各类ASM存储故障的能力。

快速的恢复是服务连续性的有力保障，以下是这次恢复案例的概要介绍。
收到某客户的服务请求，客户的数据库无法启动，磁盘组出现如下错误：

*** 2010-06-17 14:03:58.522
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kfcChkAio01], [], [], [], [], [], [], []
ORA-15196: invalid ASM block header [kfc.c:5552] [hard_kfbh] [3057] [2147483648] [4 != 13]

这个错误是由于ASM元数据损坏导致的，kfcChkAio01这个提示可以看出错误和磁盘检查有关。猜测这个错误的含义是：kernel file check Check aio error。如果不是存储问题，那么就是磁盘组出现了异常。而这个案例正是磁盘组的异常导致的。这种情况非常偶然和少见，恢复的难易程度取决于损坏元数据的多少，需要做的是通过kfed去校验和修复损坏的元数据。

这个错误的产生原因值得借鉴，我们要学会怎样规避一些异常的风险，规避风险比解决问题更重要：

• 客户在大批量导入数据时数据库挂起
• 客户 shutdown abort停止了数据库实例
• 客户shutdown abort关闭了ASM实例

在这样的步骤之后，数据库无法启动了。

这样的案例2月份我曾经遇到过一次，另外一个银行客户，同样在RAC环境中，由于多次异常关闭数据库之后，数据库因为ORA-00600 6006错误无法启动，我们同样艰难的帮助用户恢复了数据。

所以这里我想说的是，学会如何规避风险往往比知道如何解决问题更重要，因为数据库的风险太多且无处不在。