[摘要]
国家认证认可监督管理委员会,用于正常工作的一个重要ORACLE数据库,存储于LINUX EXT3文件系统之上。一次,管理员在建立测试库时选错了服务器,在ORACLE平台CREATE了一套新库,创建至10%左右时发现异样,取消、停下操作。
再次查看数据库目录,只剩余SYSTEM2.DBF一个库,其他重要的库(主要为SYSTEM1.DBF)丢失。
因数据至关重要,多家数据恢复公司同时上门进行恢复操作,我们提供的解决方案客户完全接受,于是直接将此次数据恢复的重任交给了我们。
国家认证认可监督管理委员会,用于正常工作的一个重要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工程师通过对中间数据进行分析、重组,重新导入新库中,客户需要的数据恢复成功!
常规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]相关文章。
有关LINUX 误删除方面的应急处理,请参阅 [url]WWW.SJHF.NET[/url]相关文章。
本文转自 张宇 51CTO博客,原文链接:http://blog.51cto.com/zhangyu/33749,如需转载请自行联系原作者