成功数据恢复一例LINUX EXT3 下误删除ORACLE数据库-阿里云开发者社区

开发者社区> 数据库> 正文

成功数据恢复一例LINUX EXT3 下误删除ORACLE数据库

简介:
[摘要]
    国家认证认可监督管理委员会,用于正常工作的一个重要ORACLE数据库,存储于LINUX EXT3文件系统之上。一次,管理员在建立测试库时选错了服务器,在ORACLE平台CREATE了一套新库,创建至10%左右时发现异样,取消、停下操作。
    再次查看数据库目录,只剩余SYSTEM2.DBF一个库,其他重要的库(主要为SYSTEM1.DBF)丢失。
    因数据至关重要,多家数据恢复公司同时上门进行恢复操作,我们提供的解决方案客户完全接受,于是直接将此次数据恢复的重任交给了我们。
[分析与恢复]
    常规EXT3误删除的数据恢复较为困难,且目前市面上没有可以处理这类灾难的软件,故绝大多数数据恢复公司面对此问题时手足无措,但EXT3的误删除通过一定的算法是有很大机会恢复的。
    首选的恢复方案是直接重建原先文件的属性节点,即主要恢复原文件的大小、存储位置等信息。通过节点重新描述文件。
    如此方法不通,则可以按ORACLE本身的页面结构特征进行分析与恢复。
    通过自主开发的应用于LINUX EXT3误删除的软件,很幸运地找到了一些ORACLE数据库文件,于是马上导出。。。不料,导出的SYSTEM1结构完好,却只有200M左右。与客户描述的32GB相差很远。
    仔细分析,确认导出的SYSTEM1.DBF为用户创建测试库时生成的库,因未全部做完便取消,故只占很小的初始化空间,与原数据库无关。
    重新对全盘进行详细扫描,配合ORACLE本身结构,锁定原SYSTEM1.DBF的数据区,但明显的是,已经被现在生成的约700M左右的新库(好几个)覆盖了。
    客户心情如焚,于是硬下决心,尽最大能力将其余30G左右数据成功导致。
    验证后,发现,导出的30G左右数据结构完好,无损坏,但因头部库结构及字典均遭受破坏,无法重现,故只能从数据完好的30G区域内找数据。
    ORACLE工程师通过对中间数据进行分析、重组,重新导入新库中,客户需要的数据恢复成功!
[后记]
    有关LINUX 误删除方面的应急处理,请参阅[url]WWW.SJHF.NET[/url]相关文章。




本文转自 张宇 51CTO博客,原文链接:http://blog.51cto.com/zhangyu/33749,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章