点击上方蓝字关注我们～
我们的文章会在微信公众号“Oracle恢复实录”和博客网站“rescureora.com” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
今天来到TRUNCATE TABLE恢复系列的第四篇，也是收官之作。在上篇《TRUNCATE TABLE恢复系列三：终极大招，BBED修改元数据恢复被TRUNCATE的表》中收到多人反馈说技术写得太难，不使用，看不懂。所以临时写了一篇简单又实用的方法，利用ODU软件来实现快速恢复。ODU为付费软件，官方地址为www.oracleodu.com，如果需要恢复非SYSTEM表空间的数据是需要购买授权的。本次实验是将表创建在SYSTEM表空间，不影响本次实验的结果和操作的步骤。
为了更加真实的模拟环境，这里我们将表进行多次truncate操作。
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支持lob表的恢复，在前面提到的bbed的方法对于lob表的恢复是非常麻烦的，基于存储过程的恢复是直接不支持lob表的。
在下期中我们将同时进行2个系列的恢复分享：
1.比特币中毒后恢复案例的分享
2.恶意程序清空TAB$表的恢复案例分享
我们下周再见。
Oracle恢复实录
rescureora.com
欢迎扫码关注
