共计 726 个字符，预计需要花费 2 分钟才能阅读完成。
数据库数据恢复环境：
LINUX EXT3 文件系统，部署 ORACLE 数据库。
数据库故障 & 剖析：
管理员在建设测试库时选错了服务器，在 ORACLE 数据库平台上 CREATE 了一套新库，创立至 10% 左右时发现异常，停止操作。
查看数据库目录发现只剩下 SYSTEM2.DBF 这一个库，其余的库（次要为 SYSTEM1.DBF）失落。
通过北亚数据恢复工程师团队通过会诊，最终确定了计划：
间接重建原先文件的属性节点，即次要复原原文件的大小、存储地位等信息。通过节点从新形容文件。
如果上述办法不可行，能够依照 ORACLE 数据库的页面结构特征进行剖析与复原。
数据库数据恢复过程：
1、对故障数据库所波及到的硬盘做镜像备份，后续的数据恢复操作在镜像备份文件上进行，防止对原始数据造成二次毁坏。
2、通过北亚自主开发的针对 LINUX EXT3 文件系统误删除的复原软件，咱们找到了一些 ORACLE 数据库文件，导出后发现导出的 SYSTEM1 尽管构造完整，但文件大小与用户形容的文件大小相差很远。
3、通过仔细分析，确认导出的 SYSTEM1.DBF 为用户创立测试库时生成的库，因未全副生成便被勾销，所以只占用了很小的初始化空间，与原数据库无关。
4、从新对全盘进行扫描，联合 ORACLE 自身的构造，锁定原 SYSTEM1.DBF 的数据区，但发现这块数据区曾经被新生成的几个新库笼罩了。
5、通过北亚数据恢复工程师的致力，将用户形容大小的失落的数据胜利导出。但通过验证后发现，导出的数据尽管构造完整、无损坏，但因头部库构造及字典均蒙受毁坏，无奈重现，只能在数据完整的区域内再次查找数据。
6、ORACLE 工程师通过对两头数据进行剖析、重组，从新导入到新库中并进行验证，最终用户确认所须要的数据曾经全副复原。
