dmp文件查看表空间_TRUNCATE TABLE恢复系列四：无可奈何，利用ODU还原被TRUNCATE表...

点击上方蓝字关注我们～

我们的文章会在微信公众号“Oracle恢复实录”和博客网站“rescureora.com” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！

今天来到TRUNCATE TABLE恢复系列的第四篇，也是收官之作。在上篇《TRUNCATE TABLE恢复系列三：终极大招，BBED修改元数据恢复被TRUNCATE的表》中收到多人反馈说技术写得太难，不使用，看不懂。所以临时写了一篇简单又实用的方法，利用ODU软件来实现快速恢复。ODU为付费软件，官方地址为www.oracleodu.com，如果需要恢复非SYSTEM表空间的数据是需要购买授权的。本次实验是将表创建在SYSTEM表空间，不影响本次实验的结果和操作的步骤。

创建测试表

模拟多次truncate

为了更加真实的模拟环境，这里我们将表进行多次truncate操作。

下载ODU软件

ODU软件的操作方法非常简单，请直接查看ODU手册：http://www.oracleodu.com/soft/ODUUserGuide_cn.pdf

编辑control.txt文件 

既然是数据抽取，那么需要编辑control.txt，类似于oracle的控制文件，#号标注的是每个栏位的含义，将ts#,fno,rfno全部设置为0，odu将通过读取数据文件头把后面的信息读取出来。如果数据文件头损坏则需要手工编辑。

#ts fno rfno filename block_size is_big_file header_offset blocks
0 0 0 /u01/app/oracle/oradata/rescureora/datafile/o1_mf_system_gx4pofo6_.dbf
0 0 0 /u01/app/oracle/oradata/rescureora/datafile/o1_mf_sysaux_gx4pp1yd_.dbf
0 0 0 /u01/app/oracle/oradata/rescureora/datafile/o1_mf_undotbs1_gx4ppfxg_.dbf
0 0 0 /u01/app/oracle/oradata/rescureora/datafile/o1_mf_users_gx4pq47j_.dbf
0 0 0 /u01/app/oracle/oradata/rescureora/datafile/o1_mf_test_gx4wvds6_.dbf

获取lisence 

如果需要恢复非SYSTEM表空间数据，请购买序列号。

编辑config.txt 

主要编辑charset_name字符集和output_format输出格式(dmp或者text)，dmp类似于exp导出的dmp，可以通过imp导入；text类似于sqlload的文本文件，可以通过sqlload导入。如果数据库非标准块，还需要设置block_size。

use_scanned_lob  yes
trim_scanned_blob yes
byte_order little
block_size 8192
block_buffers 1024
db_timezone -7
client_timezone 8
asmfile_extract_path /asmfile
data_path data
lob_path /odu/data/lob
charset_name AL32UTF8
ncharset_name AL16UTF16
output_format text
lob_storage infile
clob_byte_order big
trace_level 1
delimiter |
unload_deleted no
file_header_offset 0
is_tru64 no
record_row_addr no
convert_clob_charset yes
use_scanned_lob yes
trim_scanned_blob yes
lob_switch_dir_rows 20000
db_block_checksum no
db_block_checking no
rdba_file_bits 10
compatible 10

使用odu 

进入odu，unload字典信息，unload dict原理是通过读取1号文件文件头的root rdba，找到bootstrap$的段头块，再读取bootstrap$，加载数据字典信息，和oracle bootstrap原理是一样的。

扫描所有数据文件 

ODU> scan extent


scan extent start: 2019-12-01 00:02:41
scanning extent...
scanning extent finished.
scan extent completed: 2019-12-01 00:03:16

完成后会生成ext.odu文件，后面的unload抽取操作将依赖于该文件。

[oracle@rescureora odu]$ ls -l ext.odu
-rw-r--r-- 1 oracle oinstall 249059 Dec 1 00:03 ext.odu

抽取数据 

odu抽取数据unload命令有3种方式：

1.unload table rescureora.test

2.unload table rescureora.test object truncate

3.unload table rescureora.test object dataobj#

odu也支持desc命令，原理是通过之前unload dict生成的obj.odu、col.odu、tab.odu来获取表元数据信息，包括段头块位置(TS#=0 File#=1 Block#=95120)。

(1)unload table rescureora.test

这种方式的原理是读取tab.odu信息找到段头块，根据段头的extent map抽取数据，很明显这种方式不能用于恢复truncate。

(2)unload table rescureora.test object truncate

这种方式的原理是从段头块后面的第一个块依次读取第一个extent，找到第一个dataobj#小于段头dataobj#，然后根据扫描出来的ext.odu来进行抽取。该方式适用于恢复最后一次truncate前的数据，且第一个extent不被覆盖或没有完全覆盖的情况。

(3)unload table rescureora.test object dataobj#

这种方式的原理是直接指定dataobj#来进行抽取，抽取依据是扫描出来的ext.odu，具体应该使用哪个dataobj#，之前几篇文章有介绍可以通过logminer或者redodump来获取。

ODU方法总结

ODU方法是本次修复系列提供的几种方法中 最简单，最完善的方法。

最简单：只需要几条命令就可以恢复。

最完善：因为ODU支持lob表的恢复，在前面提到的bbed的方法对于lob表的恢复是非常麻烦的，基于存储过程的恢复是直接不支持lob表的。

下期知识预告

在下期中我们将同时进行2个系列的恢复分享：

1.比特币中毒后恢复案例的分享

2.恶意程序清空TAB$表的恢复案例分享

我们下周再见。

  往期回顾

• 重磅福利来袭！！快来查收吧~

• TRUNCATE TABLE恢复系列三：终极大招，BBED修改元数据恢复被TRUNCATE的表

• TRUNCATE TABLE恢复系列二：PL/SQL恢复

• TRUNCATE TABLE恢复系列一：深层剖析内部原理

• 19c grid asm intermediate故障分享

• Oracle 数据库安装系列一：19C 软件安装和补丁升级

• Oracle Data Guard系列第一讲：STANDBY DATABASE的前世今生

Oracle恢复实录

rescureora.com

欢迎扫码关注

你点的每个好看，我都认真当成了喜欢