恩墨科技成功帮助某金融用户恢复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去校验和修复损坏的元数据。

很幸运我们在1个小时之内快速帮用户改好了损坏的元数据，成功挂载磁盘，启动了数据库。恩墨科技已经具备了帮助用户恢复ASM存储故障的能力。

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

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

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

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

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