那么恢复删除的数据跟上面提到的Row Flag有什么关系呢？注意到Row Flag中有一位是用来标示当前的行有没有被删除(Deleted)，正常情况下这个bit是没有被set的，一旦当前行被删除了，这个bit就会被set了，而该行的数据并没有实际从block中擦除掉。因此一种很自然的想法就是，能不能通过简单地修改这个标识位，来恢复删除的数据呢？ 答案自然是肯定的。

首先建立一个测试表，如下...

SQL> select * from test;

ID NAME
---------- ----------
1 Frank
2 Fraud

SQL> alter system dump datafile 4 block 388;

查看dump文件可以看到这两条记录...

block_row_dump:
tab 0, row 0, @0x1f8c
tl: 12 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 02
col 1: [ 5] 46 72 61 6e 6b
tab 0, row 1, @0x1f80
tl: 12 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 03
col 1: [ 5] 46 72 61 75 64

如果现在删除第二行数据，再看看dump文件内容有什么变化...

SQL> delete from test where id = 2;

1 row deleted.

SQL> commit;

Commit complete.

SQL> alter system dump datafile 4 block 388;

System altered.

查看dump文件...

block_row_dump:
tab 0, row 0, @0x1f8c
tl: 12 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 2] c1 02
col 1: [ 5] 46 72 61 6e 6b
tab 0, row 1, @0x1f80
tl: 2 fb: --HDFL-- lb: 0x2
end_of_block_dump

注意表中的第二行数据的标志位图信息由--H-FL--变成了--HDFL-- 第四个标志位被置成了D(deleted), 表示第二行数据被删除了。

数据被删除了，只是相应地更新了那一行的标志位，数据在block上还是存在的，可以通过bbed的输出来验证这一点...

BBED> set dba 4, 388
DBA 0x01000184 (16777604 4,388)

BBED> p kdbr
sb2 kdbr[0] @118 8076
sb2 kdbr[1] @120 8064

BBED> p *kdbr[1]
rowdata[0]
----------
ub1 rowdata[0] @8164 0x3c

BBED> x /rnc
rowdata[0] @8164
----------
flag@8164: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)
lock@8165: 0x02
cols@8166: 0

BBED> dump /v dba 4, 388 offset 8164
File: /u01/app/oracle/oradata/orcl/users01.dbf (4)
Block: 388 Offsets: 8164 to 8191 Dba:0x01000184
-------------------------------------------------------
3c020202 c1030546 72617564 2c000202 l <...�..Fraud,...
c1020546 72616e6b 01069bdb l �..Frank...

<16 bytes per line>

BBED>

从上面的输出可以看到第二行的标志位（值变成了0x3c）多了一个KDRHFD,表示这一行被删除了，但是从dump命令的输出可以看出数据(Fraud)还是存在的。只要这部分的数据没有被覆盖掉，应该可以通过修改数据行的标志位信息，把数据恢复回来的。

那么怎么去修改这个标志位呢，其实想想应该也不困难，只要找到标志位的offset， 通过modify命令将值从0x3c改回成0x2c就可以了。

从上面的examine命令的输出结果，可以得到第二行数据的标志位的offset为8164，那么改变这个值就不是难事了...

BBED> modify /x 2c offset 8164
File: /u01/app/oracle/oradata/orcl/users01.dbf (4)
Block: 388 Offsets: 8164 to 8191 Dba:0x01000184
------------------------------------------------------------------------
2c020202 c1030546 72617564 2c000202 c1020546 72616e6b 01069bdb

<32 bytes per line>

BBED> dump /v dba 4, 388 offset 8164
File: /u01/app/oracle/oradata/orcl/users01.dbf (4)
Block: 388 Offsets: 8164 to 8191 Dba:0x01000184
-------------------------------------------------------
2c020202 c1030546 72617564 2c000202 l ,...�..Fraud,...
c1020546 72616e6b 01069bdb l �..Frank...

<16 bytes per line>

BBED> p *kdbr[1]
rowdata[0]
----------
ub1 rowdata[0] @8164 0x2c

BBED> x /r
rowdata[0] @8164
----------
flag@8164: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8165: 0x02
cols@8166: 2

col 0[2] @8167: 0xc1 0x03
col 1[5] @8170: 0x46 0x72 0x61 0x75 0x64

BBED> x /rnc
rowdata[0] @8164
----------
flag@8164: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8165: 0x02
cols@8166: 2

col 0[2] @8167: 2
col 1[5] @8170: Fraud

从上面的输出可以看出，这条数据已经被“恢复”回来了。那么剩下要做的事情就是更新block的checksum， 

BBED> sum dba 4, 388 apply
Check value for File 4, Block 388:
current = 0x4fb9, required = 0x4fb9

现在通过SQL访问表TEST看看数据有没有被“恢复”回来...

SQL> alter system flush buffer_cache;

System altered.

SQL> select * from test;

ID NAME
---------- ----------
1 Frank
2 Fraud

SQL>

很显然，第二行数据被“恢复”回来了。