ORACLE数据库故障解决方案

故障类型：基于ORACLE数据库环境的常见数据丢失故障。

典型特征： a ORACLE数据库无法启动或无法正常工作；

                 b ORACLE ASM存储破坏

                 c ORACLE数据文件丢失

                 d ORACLE数据文件部份损坏

                 e ORACLE DUMP文件损坏。

恢复流程

检测流程

                 a　检测是否存在硬件故障，如硬件故障，先解决硬件故障；

                 b　以只读方式检测故障表现，并参考客户对故障的描述。

恢复流程

                 a　以只读方式对故障存储做完整镜像备份，只对镜像盘操作，保证原盘数据不被破坏；

                 b　在备份中进行数据分析及恢复操作；

                 c　恢复后的数据会暂存在另一个安全的存储，避免对原数据的覆盖。

验收流程

                  a　对已恢复数据做容量及数量统计，是否与数据丢失前吻合；

                  b　对已恢复的数据做完整性验证，确保文件节点及底层逻辑等方面正确无误；

                  c　对客户指定的关键文件进行重点验证，确保客户关键数据成功恢复。

恢复的成功率

1. ORACLE数据库无法启动或无法正常工作

   如果突发性的出现上述故障，通常可恢复性极高。从技术底层上看，如果SYSTEM表未损坏，数据较易恢复；如果SYSTEM表损坏，数据需要人工核对表结构，恢复工作较为耗时。

2. ORACLE ASM存储破坏

   如ASM重置，或组成ASM的部份设备成员故障，出错后无大量新数据写入，恢复成功率较高。

3. ORACLE数据文件丢失

   无论ORACLE数据文件是删除、格式化还是未知原因丢失，只要没有新的数据写入，都可以通过ORACLE内部的数据组织规则将数据文件恢复出来，但数据文件的名称则需人工核对。

4. ORACLE数据文件部份损坏

   如ORACLE数据文件部份损坏（如覆盖），通过复杂的数据提取和重组，通常可以将未

   损坏部份的数据记录恢复出来，并可新建表追加进去，但工作量会相当大。

5. ORACLE DUMP文件损坏

   ORACLE DUMP文件损坏，将损坏部份去除，其余部份均可正常追加至数据表。

数据安全科普

1.针对软件故障，在数据丢失后，应尽可能减小对存储的操作，有时候，即使是开着机，什么也不做，也可能导致灾难进一步加剧，条件允许的话，最好损坏后，对磁盘车匪路霸存储卷做完整备份；

2.针对硬盘故障，在设备无法正常工作后，应尽可能少的加电，以避免设备的进一步损坏。

3. 做好备份方案，尽可能避免单存储备份，如数据非常重要，可考虑异地备份。

选择服务商的标准

　　数据恢复有别于一般维修行业，目前市场鱼龙混杂，不同服务商的技术水平和职业素质千差万别，数据丢失后交由非专业人员进行各种检测与恢复操作造成盘片划伤、数据完全覆盖，最终数据无法恢复的情况常有发生，用户从寻找低价到不惜代价拯救数据的例子比比皆是。因此，恢复重要数据必须寻求专业、正规的数据恢复公司帮助，切勿贪图便宜造成无法挽回的损失。是否专业考量的因素有：

设备，拥有独立的无尘洁净间，保证开盘操作在百级无尘的洁净环境下进行，市场上很多数据恢复公司都表示有无尘洁净室，但事实上能让客户亲眼所见的只是凤毛麟角，寥寥可数。

技术，就像病重的人手术一样，资深数据恢复工程师对硬件和逻辑结构均有丰富经验，能果断准确地判定该如何抢救数据，机会可能只有一次，有时一次的误操作足以让数据返魂乏术。

效率，一般情况下普通故障当天能完成，即使开盘恢复也只1-3天，需要一段时间才能完成的极有可能是中间商，即接单后转给第三方赚取差价，成功率与数据安全毫无保障。