Oracle数据恢复:格式化,Raid损坏,文件覆盖恢复
最近接触了几则客户的Oracle数据库恢复案例,记录一下供大家参考。
案例一:
某客户为了重新部署系统,将数据导出备份到移动硬盘,然后将Raid重新格式化,重新安装系统,当进行Oracle数据库重建,导入数据时发现,移动硬盘上的数据无法正确读取,文件缺失一半。数据灾难形成。
导入数据时出现 IMP-00009 错误,和以下文章描述的状况是相同的:
http://www.eygle.com/archives/2009/05/imp_00009_abnormal_end.html
我到现场进行分析,发现文件的确只复制了一半,丢失了大约200张数据表的数据。通过备份恢复数据已经不可能。
最后只有一种方式,就是从被格式化的硬盘上进行碎片重组,找回数据,最终这条路成功了,通过硬盘恢复找回数据恢复了业务运行。
这个案例给我们的提示是:重要数据,备份需要多留拷贝,在进行备份验证之前,备份的可靠性不能轻信。
案例二:
某用户,SUN的存储阵列,已经持续运行了7年,最后存储的Raid中,同时损坏了两块硬盘,热备盘早已损坏,但是由于存储所有的绿灯都亮,用户一直以为存储正常无故障运行。
此次故障出现,存储罢工,数据库服务无法提供,用户没有备份。
我们到现场,只有一个途径,就是通过存储级别恢复数据,找回文件,虽然磁盘出现故障,但是数据仍然是完好的,通过计算奇偶校验,回复数据,然后最终修复启动了数据库,在数据库级别存在坏块,不一致,通过BBED,隐含参数等,可以成功打开数据库。
这个案例给我们的提示是:硬件和人一样,过劳都会出现灾难,请大家注意健康。
在微博上,有朋友说,硬件总会出问题,要多监控就应当能够及时预警,我的观点是:
再严密的部门,再严密的监控,总有疏忽,这样的疏忽,有很多大牛的公司都犯过,我们也经历过,所以大家应当共同警示吧。细心多一万分不多,粗心就一次致命。
案例三:
某用户,构建大型的ERP系统,在部署初始化环境时,由于疏忽,在安装数据库时,覆盖了原有的一个重要数据库。形成数据灾难。
对于这类操作,通常覆盖的只是SYSTEM表空间、UNDO表空间、Users表空间等,数据表空间通常不会覆盖,但是如果数据结构复杂,通过DUL等工具去抽取数据会根本不可实现。
在2006年我处理过同样一则案例,首先是在存储级别恢复了SYSTEM表空间,排除覆盖掉的部分,大部分数据完好,结合这部分数据和剩余的数据文件,可以较为迅速的恢复数据。
我在微博的记录是:本想早点睡觉,又收到用户的紧急求助电话,用户在安装数据库时,因为疏忽,覆盖了之前载有重要数据的数据库。系统表空间等重要文件被覆盖,又是一个极大的灾难。搞技术的同学们要谨记:在做破坏性、创建性操作时,一定要慎之又慎。
这些案例与大家共为警醒。
建议继续学习:
- RAID磁盘阵列学习笔记 (阅读:6079)
- 利用binlog来恢复数据库 (阅读:4113)
- 这样恢复 Linux 分区下误删的文件 (阅读:4102)
- 恢复删除的数据表,数据库 (阅读:3873)
- Oracle数据恢复专题 (阅读:3839)
- Mysql .frm损坏后如何恢复 (阅读:3492)
- Oracle数据恢复 - Linux / Unix 误删除的文件恢复 (阅读:3444)
- MySQL数据库InnoDB数据恢复工具使用总结 (阅读:3198)
- linux上ext2文件系统中,用debugfs来恢复被删除的文件 (阅读:2891)
- 实例:Linux EXT3文件系统下成功恢复误删的文件 (阅读:2722)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:eygle@eygle.com(eygle) 来源: Oracle Life
- 标签: Raid 数据恢复
- 发布时间:2011-11-23 23:44:39
- [67] Go Reflect 性能
- [67] Oracle MTS模式下 进程地址与会话信
- [67] 如何拿下简短的域名
- [61] IOS安全–浅谈关于IOS加固的几种方法
- [60] 图书馆的世界纪录
- [59] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [47] 界面设计速成