| 网站首页 | 数据恢复资料 | 数据恢复软件 | 咨询留言 | 数据恢复博客 | 数据恢复论坛 | 
Calendar
正在载入数据恢复博客,请稍等......
Placard
正在载入数据恢复博客,请稍等......
Category
正在载入数据恢复博客,请稍等......
Latest Entries
正在载入数据恢复博客,请稍等......
Latest Comments
正在载入数据恢复博客,请稍等......
Last Messages
正在载入数据恢复博客,请稍等......
User Login
Links
Information
正在载入数据恢复博客,请稍等......
Search
Other
Welcome to my blog!
  成功数据恢复一例LINUX EXT3 下误删除ORACLE数据库
 

[申明]
    转载请保留原作网站:http://www.sjhf.net 关键字[LINUX误删除数据恢复]

[摘要]
    国家认证认可监督管理委员会,用于正常工作的一个重要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 误删除方面的应急处理,请参阅WWW.SJHF.NET相关文章。
   

[ 阅读全文 | 回复(0) | 引用通告 | 编辑

  Post  by  张宇 发表于 2007-2-8 19:06:55

发表评论:

    昵称:
    密码:
    主页:
    标题:
    正在载入数据恢复博客,请稍等......
正在载入数据恢复博客,请稍等......
版权所有:http://www.sjhf.net(数据恢复)