[摘要]
    国家认证认可监督管理委员会，用于正常工作的一个重要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]相关文章。