最近接触了几则客户的Oracle数据库恢复案例,记录一下供大家参考。

    案例一：

    某客户为了重新部署系统，将数据导出备份到移动硬盘，然后将Raid重新格式化，重新安装系统，当进行Oracle数据库重建，导入数据时发现，移动硬盘上的数据无法正确读取，文件缺失一半。数据灾难形成。

    导入数据时出现　IMP-00009　错误，和以下文章描述的状况是相同的：

    http://www.eygle.com/archives/2009/05/imp_00009_abnormal_end.html

    我到现场进行分析，发现文件的确只复制了一半，丢失了大约２００张数据表的数据。通过备份恢复数据已经不可能。

    最后只有一种方式，就是从被格式化的硬盘上进行碎片重组，找回数据，最终这条路成功了，通过硬盘恢复找回数据恢复了业务运行。

    这个案例给我们的提示是：重要数据，备份需要多留拷贝，在进行备份验证之前，备份的可靠性不能轻信。

    案例二：

    某用户，SUN的存储阵列，已经持续运行了７年，最后存储的Raid中，同时损坏了两块硬盘，热备盘早已损坏，但是由于存储所有的绿灯都亮，用户一直以为存储正常无故障运行。

    此次故障出现，存储罢工，数据库服务无法提供，用户没有备份。

    我们到现场，只有一个途径，就是通过存储级别恢复数据，找回文件，虽然磁盘出现故障，但是数据仍然是完好的，通过计算奇偶校验，回复数据，然后最终修复启动了数据库，在数据库级别存在坏块，不一致，通过BBED，隐含参数等，可以成功打开数据库。

    这个案例给我们的提示是：硬件和人一样，过劳都会出现灾难，请大家注意健康。

    在微博上，有朋友说，硬件总会出问题，要多监控就应当能够及时预警，我的观点是：

    再严密的部门，再严密的监控，总有疏忽，这样的疏忽，有很多大牛的公司都犯过，我们也经历过，所以大家应当共同警示吧。细心多一万分不多，粗心就一次致命。

    案例三：

    某用户，构建大型的ERP系统，在部署初始化环境时，由于疏忽，在安装数据库时，覆盖了原有的一个重要数据库。形成数据灾难。

    对于这类操作，通常覆盖的只是SYSTEM表空间、UNDO表空间、Users表空间等，数据表空间通常不会覆盖，但是如果数据结构复杂，通过DUL等工具去抽取数据会根本不可实现。

    在２００６年我处理过同样一则案例，首先是在存储级别恢复了SYSTEM表空间，排除覆盖掉的部分，大部分数据完好，结合这部分数据和剩余的数据文件，可以较为迅速的恢复数据。

    我在微博的记录是：本想早点睡觉，又收到用户的紧急求助电话，用户在安装数据库时，因为疏忽，覆盖了之前载有重要数据的数据库。系统表空间等重要文件被覆盖，又是一个极大的灾难。搞技术的同学们要谨记：在做破坏性、创建性操作时，一定要慎之又慎。

建议继续学习：

1. RAID磁盘阵列学习笔记    (阅读：6018)
2. 这样恢复 Linux 分区下误删的文件    (阅读：4054)
3. 利用binlog来恢复数据库    (阅读：4059)
4. 恢复删除的数据表，数据库    (阅读：3834)
5. Oracle数据恢复专题    (阅读：3702)
6. Mysql .frm损坏后如何恢复    (阅读：3431)
7. Oracle数据恢复 - Linux / Unix 误删除的文件恢复    (阅读：3356)
8. MySQL数据库InnoDB数据恢复工具使用总结    (阅读：3090)
9. linux上ext2文件系统中，用debugfs来恢复被删除的文件    (阅读：2845)
10. 实例：Linux EXT3文件系统下成功恢复误删的文件    (阅读：2665)