细数基于ORACLE 数据库环境的常见数据灾难解决方式

一、故障描述：基于 ORACLE 数据库环境的常见数据灾难

故障表现：

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

2 、 ORACLE ASM 存储破坏。

3 、 ORACLE 数据文件丢失。

4 、 ORACLE 数据文件部分损坏。  

5 、 ORACLE DUMP 文件损坏。    

二、解决方案

◆ 检测      

1 、检测是否存在硬件故障，如硬件故障，转硬件处理

2 、以只读方式检测故障表现是否与用户描述相同

◆ 恢复

1 、备份：以只读方式对故障存储做完整镜像 ( 参考附录 )

2 、在备份中进行数据分析及恢复操作。

3 、通常，恢复后的数据会暂存在另一个存储体上

◆ 验收

对恢复好的数据进行验证，确认其正确性。如确认，交费 –> 移交原介质及已恢复数据 –> 出具发票 ( 收据 ) 及报告。

如无法认可数据恢复结果，交回原介质，不收服务费，可免费出具报告。

 

三、数据恢复的可能性

★  ORACLE 数据库无法启动或无法正常工作：

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

     

★  ORACLE ASM 存储破坏：

如 ASM 重置，或组成 ASM 的部分设备成员故障，出错后无大量新数据写入，数据通常可以很好的恢复。

 

★  ORACLE 数据文件丢失：

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

 

★  ORACLE 数据文件部分损坏：

如 ORACLE 数据文件部分损坏 ( 如覆盖 ) ，通过复杂的数据提取和重组，通常可以将未损坏部分的数据记录恢复出来，并可新建表追加进去，但会相当耗时。

★  ORACLE  DUMP 文件损坏：

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

 

四、时间

1TB 以下的存储空间 ( 不是要恢复的数据容量 ) ，通常 2 个工作日内可完成； 1TB 以上的随存储容量的增加，恢复周期通常也会增加。

数据表如果很大，提取数据、整理数据也会花费大量时间，具体时间需据具体情况而定。

 

[ 小贴士 ]

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

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

   

如何避免    

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31380569/viewspace-2650931/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31380569/viewspace-2650931/