oracle异常恢复（一）dul和bbed的使用-睿象云平台

oracle异常恢复（一）dul和bbed的使用

本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。

oracle异常恢复（一）dul和bbed的使用

日常工作中，我们经常会使用各种各样的工具进行辅助，但实际上工具本身的使用一般都很简单，比熟练使用工具更重要的是理解他的实现原理。本篇文章笔者将介绍与oracle异常恢复相关的两个工具的使用以及他们的实现原理（bbed和dul）。

申明一点：既然说是异常恢复，所以本文中默认数据库是没有备份的也未开启归档模式。

在进入正题之前，我们先来试想几个问题：

如果在生产环境中truncate了一张表，还能恢复吗？如果可以该如何恢复？如果在生产环境中offline了一个数据文件，等想再次online的时候，发现介质恢复所需要的redo log已经被覆盖了，还能恢复吗？如果可以该如何恢复？如果在生产环境中误删了一个业务用户，还能恢复吗？如果可以该如何恢复？

对于第一个问题，答案当然是肯定的（可能会丢失数据，也可能不会丢），其实回答这个问题之前我们首先需要知道truncate这个动作到底都做了些什么，其中最重要的一步就是清空段的extent map（extent map中记录了哪些文件哪些块是属于这张表的），而truncate的动作只是将extent map的映射关系给清除了，而实际的物理数据文件以及数据块中的数据都还是存在的，这些块在被重用之前并没有被清除，所以这些块还没有被重用就还能被恢复。这里插一句，其实我们可以在truncate表的时候加相应参数以达到不同的效果，例如drop storage（清空数据，只保留一个分区结构）、reuse storage（清空数据，段结构不回收）以及drop all storage等，这里不再展开。

既然我们已经知道了数据能否恢复的关键前提（数据块未被重用），那么当我们遇到这种情况的时候，首要的任务就是将该表所在的相关表空间置为read only。

alter tablespace tablespace_name read only;

环境以及测试数据准备

create tablespace tbs0805 datafile '/u01/app/oracle/oradata/ces/tbs0805.dbf' size 10M autoextend off;

create user test0805 identified by test0805 default tablespace tbs0805;

grant dba to test0805;

conn test0805/test0805

create table tb0805(id number,name varchar2(20),other_col char(2000));

begin

for i in 1..100 loop

insert into tb0805 values (i,'i_a','i_a');

end loop;

end;

commit;

select object_id,object_name,data_object_id from dba_objects where object_name='TB0805';

接下来我们先来验证一下truncate所做的内容是不是如我们前面所说的那样我们先看下刚刚创建的表tb0805的段信息：

select extent_id,file_id,block_id,blocks from dba_extents where segment_name='TB0805';

我们再dump段头块查看段头中extent map长什么样：

oradebug setmypid

alter system dump datafile 11 block 170;

oradebug tracefile_name

接下来再dump一个非段头数据块：

oradebug setmypid

alter system dump datafile 11 block 188;

oradebug tracefile_nam

我随机挑了一个块（11号文件的188号块）从上图可以看出，该块为存储业务数据的块，并且这里有一点需要注意：数据块中是不会存储表的名字、表中列的名字以及列的类型的，列的名字用col 0，col 1，col 2等代替。

truncate表tb0805

truncate table tb0805;

select object_id,object_name,data_object_id from dba_objects where object_name='TB0805';

前面已经提到truncate这个动作实质上只是清除段头的extent map映射关系，其实truncate时还有一个动作，就是将data_object_id值加1，上面图片显示tb0805的data_object_id为90715是因为笔者在环境中truncate不止一次。

再次查看truncate之后tb0805的段信息

select extent_id,file_id,block_id,blocks from dba_extents where segment_name='TB0805';

此时发现只剩下一个区段信息，这个区段虽然还是原来11号文件，168号块及后面的7个块，但是oracle现在已经认为这是一个新的段，这也就解释了为什么truncate之后data_object_id值会增加的原因了。

现在再次dump段头块确认truncate之后其发生的变化

oradebug setmypid

alter system dump datafile 11 block 170；

oradebug tracefile_name

可以发现段头块中extent map信息和前面查询到的结果是一致的。

再次dump一个非段头块，这里继续dump前面选择的11号文件188号块

oradebug setmypid

alter system dump datafile 11 block 188;

oradebug tracefile_name

可以发现，与前面我们对这个块dump时的内容是一样的，到这里我们就基本确认了truncate动作只是清除extent map映射关系，而实际的数据文件以及其中的块的信息是没有被清理的。

既然这些数据文件中的块信息没有被清理，那么我们能不能保证在块不被重写之前，将块中的数据抽取出来再利用函数转换成可视化数据，然后再插回表中呢？当时是可以的，dul工具就是做这样一件事的。

dul是oracle原厂推出的非常规的恢复工具，他是按照db_block_size，去扫描被truncate表所在表空间的数据文件中的每一个block，如果这个block的对象id是误truncate表之前该表的object_id的话，就把里面的数据利用工具抽取出来，从而实现数据恢复。由于dul工具暂无法获取，这里使用了别人的测试案例，该案例演示了将误truncate的表恢复回来。

既然我们已经知道了dul的工作原理，那么当一张表被truncate时我们具体该怎么做呢？现在我们将思路再捋一捋：

某一张表被truncate了查出该表属于哪个表空间将该表空间置为read only查出该表空间的表空间号以及其包含的数据文件配置dul工具所需的参数文件启动dul数据得到恢复

下面我们进行实际操作

dul工具解压后只有一个dul文件，如果使用的话，还需要配置两个参数文件，init.dul，control.dul，其中init.dul配置一些参数，例如db_block_size等，这里需要注意一个参数是osd_big_endian_flag = false（是否是大字节序），关于字节序：linux和windows都是小字节序的，unix（aix，hpux，soloris）都是大字节序的。然后control.dul配置文件中配置的即为需要dul扫描的数据文件相关信息，可以用下面的sql语句查询出来：

--先查出所属表空间（TBS0805）

select tablespace_name from dba_segments where segment_name='TB0805';

--查出表空间号（11）

select ts#,name from v$tablespace where name='TBS0805';

--查出表空间包含的数据文件

select ts#,rfile#,name from v$datafile where ts#=11;

./dulscan database;这一步结束会生成两个文件SEG.dat（记录了遇到的段头），EXT.dat（哪些extent是属于这张表的）

scan extents;set use_scanned_extent_map=true; ---用刚刚扫描的extent 的映关系作为扫描的结果unload table dul_tb0805 (id number,name varchar2(20),other_col char(2000)) storage (databjno 90517 ); --因为块中不存储表名及列名

抽取出来的数据是一个dmp文件，只需要将这个dmp文件导入到数据库中，再执行insert into tb0805 select * from dul_tb0805; 即实现了truncate表之后的恢复。

总结：我们最后再来回顾一下文章最开始的三个问题，有些问题虽然看上去很复杂，但当你搞清楚他背后的原理之后，就会发现其实也不过如此，至此第一个问题我们已经解释清楚了，那么第二第三个呢？你现在是不是已经觉得简单了呢？还是那句话，工具本身使用都很简单，比熟练使用工具更重要的是理解他的工作原理。篇幅原因，下期将带来bbed工具的使用及其原理的介绍，咱们下期再见。