基于Oracle 数据文件DBF恢复数据

1、将手头还剩下的ORACLE数据文件即扩展名一般为.DBF或.ORA的文件复制一份到恢复使用的环境操作系统上，推荐使用的操作系统为Windows或Linux。 并在Windows或Linux上安装JAVA JDK 1.6以上版本。

4、点击load 按钮，PRM会自动加载数据字典 即bootstrap动作

6、Load完成后 PRM-DUL界面左侧出现按照数据库用户分组的树形图点开USERS，可以看到多个用户名，例如用户需要恢复PD SCHEMA下的一张表，则点开PD，并双击表名：

9、首次使用数据搭桥模式时需要先创建目标数据库连接信息，这就和我们在SQLDEVELOPER中创建一个Connection是类似的工作，包括目标数据库的Host、端口、Service_Name以及用户登录信息；注意这里填选的用户信息，将会是稍后数据搭桥使用的目标数据库的User用户，即从源库这里抽取出来的表会传输到目标数据库中此处所指定的用户名下。

11、Save后进入DataBridge主界面，首先在DB Connection下拉框中选择刚刚加入的Connection G10R25:

13、正确选择DB Connection后可以Tablespace的下拉框将变得可用，选中合适的表空间：

15、注意：1）对于目标库中已经存在对应表名的情况，PRM-DUL不会重建表而是会在现有表的基础上插入所需恢复的数据，由于表已经建立了所以指定的表空间将无效 2）对于目标数据库中还不存在对应表名的情况，PRM-DUL会尝试在指定表空间上建表并插入恢复数据此场景中由于我们是恢复Truncate掉的数据，所以需要选中“if data truncated”选项，否则PRM-DUL将以常规模式抽取数据，将无法抽取到已经被Truncate掉的数据。Truncate数据的大致机理是，ORACLE会在数据字典和Segment Header中更新表的Data Object ID，而实际数据部分的块则不会做修改。由于数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不一致，所以ORACLE服务进程在读取全表数据时不会读取到已经被TRUNCATE但是实际仍未被覆盖的数据。PRM-DUL通过自动扫描被TRUNCATE掉数据段头Segment Header后续的数据块智能判断TRUNCATE前数据段的DATA_OBJECT_ID，并根据字典中的表字段定义和自动获得的原始DATA_OBJECT_ID来抽取数据。此处还存在一个”if to specify data object id”输入框，该输入框可以让用户指定要恢复的数据的Data Object ID。一般情况下不需要指定任何值，除非你发现恢复Truncate数据不成功时，建议在ParnassusData原厂工程师的帮助下指定该值。如上正确完成DataBridge配置后即可证实开始数据搭桥，只需要点击DataBridge按钮即可：