ORACLE数据库故障解决方案
浏览数:626


故障类型:基于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天,需要一段时间才能完成的极有可能是中间商,即接单后转给第三方赚取差价,成功率与数据安全毫无保障。