恩墨科技为用户提供各类ASM故障恢复服务

近日，恩墨科技帮助用户恢复了严重的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错误无法启动，我们同样艰难的帮助用户恢复了数据。

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

恩墨科技提供全面的数据恢复服务

在很多复杂的意外情况下，客户的数据库可能遭受意外的损害，这些意外可能包括：
1.存储故障，诸如硬盘损坏、Raid信息损坏、Raid组损坏多块硬盘、误删除文件等
2.数据库故障，诸如数据文件坏块、SYSTEM表空间损坏、数据文件丢失、Offline文件加载、归档日志缺失等。

针对这些复杂的问题，恩墨科技在实践中积累了全面的经验，能够帮助客户在遭遇异常的情况下，最大限度的完成数据恢复。
我们对以下场景具有全面的经验及解决方案：
1.误删除数据文件的恢复
2.误删除表空间的恢复
3.误删除数据、数据表等情况的恢复
4.存储级别的误删除恢复
5.Raid级别的损坏恢复
6.丢失SYSTEM表空间的恢复
7.丢失局部数据文件的恢复
......

在Oracle数据库方面，我们能够最大限度的挽回数据，为用户减少损失。