深入解析：TRUNCATE TABLE 的内部原理解析与恢复思路

摘要

众所周知，truncate table 是一种快速清空表内数据的一种方式，与 delete 方式不同，truncate 只产生非常少的 redo 和 undo，就实现了清空表数据并降低表 HWM 的功能。本文主要围绕 truncate table 的实现原理和 truncate table 的恢复来展开。

TRUNCATE 原理
环境准备

构造测试环境，通过 10046 以及 redo dump 去分析 truncate 的整个操作过程。
1) 10046 用于观察 truncate 对于字典基表的操作；
2) redo dump 用于观察 truncate 对于 segment header 以及 L1、L2 位图块的操作。

基于 ASSM 测试环境如下：

OS: redhat 6.5
db：11.2.0.4
segment&extent info:
SYS@:>select owner,segment_name,header_file,header_block from dba_segments where segment_name='TRUNCATE_TABLE' and owner='TEST';
OWNER                SEGMENT_NAME         HEADER_FILE     HEADER_BLOCK
-------------------- -------------------- ----------- ------------- ----------- ------------- ----------- ------
TEST                    TRUNCATE_TABLE                 5                              1898SYS@:>select extent_id,file_id,block_id,blocks from dba_extents where segment_name='TRUNCATE_TABLE' and owner='TEST' order by 1;
EXTENT_ID    FILE_ID   BLOCK_ID     BLOCKS
---------- ---------- ---------- ----------
0          5       1896          8
1          5      12104          8
2          5      12112          8
3          5      12120          8
4          5      12128          8
5          5      12136          8
6          5      12144          8
7          5      12152          8
8          5      11904          8
9          5      11912          8
10          5      11920          8
11          5      11928          8
12          5      11936          8
13          5      11944          8
14          5      11952          8
15          5      11960          8
16          5      16256        128
17          5      16384        128
18          5      16512        128
19          5      16768        128
20          5      22528        128
21          5      22656        128
22          5      22784        128
23          5      22912        128
24          5      23040        128
25          5      23168        128
26          5      23296        128
27          5      23424        128

truncate 对数据字典基表的操作

SYS@TEST(test):1>select count(*) from test.truncate_table;
COUNT(*)
----------
113426
SYS@:>alter system flush SHARED_POOL;
System altered.
SYS@:>alter system flush BUFFER_CACHE;
System altered.
SYS@:>alter system switch logfile;
System altered.
SYS@:>select * from v$log;
GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME         NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------ ------------ ------------------
1          1         85   52428800        512          1 NO  CURRENT                4116465 21-APR-18            2.8147E+14
2          1         83   52428800        512          1 NO  INACTIVE               4092314 20-APR-18               4116301 21-APR-18
3          1         84   52428800        512          1 NO  INACTIVE               4116301 21-APR-18               4116465 21-APR-18
SYS@:>oradebug setmypid;
Statement processed.
SYS@:>oradebug tracefile_name
/u01/app/oracle/diag/rdbms/test/test/trace/test_ora_7091.trc
SYS@:>oradebug event 10046 trace name context forever,level 12;
Statement processed.
SYS@:>truncate table test.truncate_table;
Table truncated.
SYS@:>oradebug event 10046 trace name context off;
Statement processed.
SYS@TEST(test):1>alter system dump logfile '/u01/app/oracle/oradata/test/redo01.log';
System altered.

从 10046 trace 里搜出对基表的 dml 操作：

update：
[root@prim1-11g ~]# grep -i "^update"  /u01/app/oracle/diag/rdbms/test/test/trace/test_ora_7091.trc
update obj$ set obj#=:4, type#=:5,ctime=:6,mtime=:7,stime=:8,status=:9,dataobj#=:10,flags=:11,oid$=:12,spare1=:13, spare2=:14 where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
update sys.mon_mods$ set inserts = inserts + :ins, updates = updates + :upd, deletes = deletes + :del, flags = (decode(bitand(flags, :flag), :flag, flags, flags + :flag)), drop_segments = drop_segments + :dropseg, timestamp = :time where obj# = :objn
update tab$ set ts#=:2,file#=:3,block#=:4,bobj#=decode(:5,0,null,:5),tab#=decode(:6,0,null,:6),intcols=:7,kernelcols=:8,clucols=decode(:9,0,null,:9),audit$=:10,flags=:11,pctfree$=:12,pctused$=:13,initrans=:14,maxtrans=:15,rowcnt=:16,blkcnt=:17,empcnt=:18,avgspc=:19,chncnt=:20,avgrln=:21,analyzetime=:22,samplesize=:23,cols=:24,property=:25,degree=decode(:26,1,null,:26),instances=decode(:27,1,null,:27),dataobj#=:28,avgspc_flb=:29,flbcnt=:30,trigflag=:31,spare1=:32,spare2=decode(:33,0,null,:33),spare4=:34,spare6=:35 where obj#=:1
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535, NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17,0,NULL,:17),scanhint=:18, bitmapranges=:19 where ts#=:1 and file#=:2 and block#=:3
delete：
[root@prim1-11g ~]# grep -i "^delete"  /u01/app/oracle/diag/rdbms/test/test/trace/test_ora_7091.trc
delete from superobj$ where subobj# = :1
delete from tab_stats$ where obj#=:1

通过上述跟踪，可以看到对基表的修改主要是：
1) 修改 obj$，tab$ 的 dataobj#
2) 修改 seg$ 的对应信息如(extents,blocks,hwmincr等等)
3) 删除 tab_stats$ 对应对象的统计信息

truncate 对元数据块的操作

对于 segment header 以及 L1、L2 位图块的操作，只能通过 redo dump 去观察。
为什么不使用 logminer 进行分析？

因为在 logminer 中只会记录数据块的变更，而对于 segment header 和 L1、L2 位图块的操作在 logminer 里只记录操作类型为 internal 或者 unsupported，没有什么有价值的信息。

通过对 redo dump 的分析，发现 truncate 操作只对 segment header，L2位图块，第一个 L1 位图块和 HWM block 所属的 L1 位图块进行了修改。

对于 segment header 的修改内容：
1) 修改块的 dataobj#
2) 修改 LHWM 和 HHWM
3) 修改 extent map、aux map 以及 extents 个数

对于 L2 位图块的修改内容：
1) 删除 L1 ranges
2) 修改L2块的dataobj#

对于第一个 L1 位图块的修改内容：
1) 修改第一个 L1 块的 dataobj#
2) set hwm 为 ext# 为 0 的第 3+1 个块(即段头块+1）

对于 HWM block 所属 L1 位图块的修改内容：
1) clear HWM flag

原理总结

truncate的实质是在不修改数据块的情况下，通过修改segment header的data_object_id,hwm,逐条清空 extent map，aux map 来实现清空表的目的，其中还涉及数据字典基表以及 L1、L2 位图块的修改，因此也可以说明 truncate 操作只是存储数据的数据块没有产生任何 redo 和 undo，但是 segment header，位图块，数据字典基表还是会产生 redo 和 undo。

TRUNCATE的恢复

本文的 truncate 恢复只针对于堆表 (非lob) 进行了测试，其实对于分区表和 lob 段的恢复原理是一样的。

根据之前对 truncate 原理的分析，truncate是不能通过闪回查询或者 logminer 的方式来恢复的，因为 truncate 操作不会对数据块进行任何操作，那么 truncate 应该如何恢复呢？下面列出几种常见的方法可供参考。
数据库闪回(要求 flashback database 开启，并且必要的闪回日志和归档日志不能丢失，因为闪回数据库不仅仅需要应用闪回日志，归档日志也是需要的)
异机恢复(要求有可用的备份以及必要的归档日志)
TSPITR(要求有可用的备份以及必要的归档日志）
特殊恢复工具恢复，如：odu(要求数据不被覆盖，如果数据被覆盖也可以最大程度的恢复数据)
通过修复元数据来实现恢复 truncate(要求有 truncate 操作时的 redo 信息，并且数据不被覆盖，如果数据被覆盖也可以最大程度的恢复数据)
其中数据库闪回和 TSPITR 对数据库影响较大。

最后两种方式可以在数据库 flashback database 没有开启，并且无备份的情况下进行恢复，但是这两种方式的技术难度大且容易制造出更大的麻烦，强烈建议不要轻易地在生产环境中进行尝试，最好还是请专业人士进行恢复（小编强行植入：云和恩墨 24h 等待各位召唤师召唤，如有紧急 case 直接在公众号任意一篇文章留言会立即帮忙联系公司专家对接，嘎嘎），本文只是为了演示最后这两种不常见的方法，重点介绍第二种修复元数据方式。

odu 的方式

odu 是 oracle 技术大咖 老熊（熊爷）开发的一款专业而且强大的 oracle 恢复工具，适用于所有场景下的恢复，具体功能介绍可以查看产品BLOG http://www.oracleodu.com/cn/。

odu 恢复 truncate 的原理是通过 scan 数据文件生成一份名为 ext.odu 的文件，该文件按照表的 dataobj# 扫描出具体的 extent 信息，然后通过 ext.odu 可以导出需要恢复的表的数据，最终再导入到数据库中，具体情况可以参看“利用 ODU 在 ASM 中恢复被 Truncate 掉的表的实例”(http://www.oracleodu.com/cn/recovery-truncated-table-in-asm-using-odu.html)

修复元数据的方式

重点介绍下通过修复元数据的方式来恢复 truncate table 的操作。

根据之前对 truncate 原理的分析，truncate 的实质是在不修改数据块的情况下，通过修改 segment header 的 data_object_id,hwm,逐条清空 extent map，aux map 等信息来实现清空表的目的，其中还涉及数据字典基表以及 L1、L2 位图块的修改，那么对于通过修改元数据的方式去恢复，大致思路如下：
确认需要恢复的数据字典基表和元数据块以及内容
确认truncate释放的空间是否被覆盖
根据前两点的分析开始进行恢复

第一个问题：如何确认哪些元数据块和数据字典是需要恢复的？
通过 10046 的跟踪发现(需要 flush shared pool 和 buffer cache)，全表扫描查询或者是通过 rowid 去查询一定会访问 segment header，但是不会去访问任何 L1、L2 位图块，访问的数据字典基表包括：
user$、obj$、tab$、
tab_stats$、ts$、seg$、
ind$、ind_stats$、col$、
objauth$、cdef$、histgrm$、
hist_head$

这里重点关注之前通过 10046 跟踪 truncate 操作有更改的基表 obj$、tab$、seg$、tab_stats$ (统计信息不用管)，其中 seg$ 经过测试只要 block#，file#，ts#(其实就是 segment header 地址)不被更改就无需理会，且 truncate 操作并不会修改 seg$ 的 ts#、file#、block#，因为 segment header 地址不会改变，验证过程如下：

SYS@TEST(test):1>select obj#,dataobj# from obj$ where owner# in (select user# from user$ where name='TEST') and name='T1';
OBJ#   DATAOBJ#
---------- ----------
17284      17284
SYS@TEST(test):1>select TS#,FILE#,BLOCK# from tab$ where OBJ#=17284;
TS#      FILE#     BLOCK#
---------- ---------- ----------
9          4        290
--修改 seg$ 的 blocks，extents，extsize，hwmincr 等信息
SYS@TEST(test):1>update seg$ set blocks=1,extents=1,minexts=1,maxexts=1,extsize=1,bitmapranges=1,hwmincr=1,type#=1 where ts#=9 and file#=4 and block#=290;
1 row updated.
SYS@TEST(test):1>commit;
Commit complete.
SYS@TEST(test):1>alter system flush shared_pool;
System altered.
--并不影响 t1 的查询
SYS@TEST(test):1>select count(*) from test.t1;
COUNT(*)
----------
14164
--删除或修改 ts#，file#，block#
SYS@TEST(test):1>delete from seg$ where ts#=9 and file#=4 and block#=290;
1 row deleted.
SYS@TEST(test):1>commit;
Commit complete.
SYS@TEST(test):1>select count(*) from test.t1;
select count(*) from test.t1
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [ktsircinfo_num1], [9], [4], [290], [], [], [], [], [], [], [], []

所以需要恢复的元数据块和数据字典基表以及内容为：

segment header(dataobj#、LHWM、HHWM、extent map、aux map以及extents个数)
tab$(dataobj#)
obj$(dataobj#)

下面提供 segment header 的信息对应的 offset：

segment header dump：
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0      spare2: 0      #extents: 28     #blocks: 1664
last map  0x00000000  #maps: 0      offset: 2716
Highwater::  0x01405b83  ext#: 27     blk#: 3      ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 1539
mapblk  0x00000000  offset: 27
Unlocked
--------------------------------------------------------
Low HighWater Mark :
Highwater::  0x01405b83  ext#: 27     blk#: 3      ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 1539
mapblk  0x00000000  offset: 27
Level 1 BMB for High HWM block: 0x01405b80
Level 1 BMB for Low HWM block: 0x01405b80
--------------------------------------------------------
Segment Type: 1 nl2: 1      blksz: 8192   fbsz: 0
L2 Array start offset:  0x00001434
First Level 3 BMB:  0x00000000
L2 Hint for inserts:  0x01400769
Last Level 1 BMB:  0x01405b81
Last Level II BMB:  0x01400769
Last Level III BMB:  0x00000000
Map Header:: next  0x00000000  #extents: 28   obj#: 16840  flag: 0x10000000
Inc # 0
Extent Map
-----------------------------------------------------------------
0x01400768  length: 8
0x01402f48  length: 8
0x01402f50  length: 8
0x01402f58  length: 8
0x01402f60  length: 8
0x01402f68  length: 8
0x01402f70  length: 8
0x01402f78  length: 8
0x01402e80  length: 8
0x01402e88  length: 8
0x01402e90  length: 8
0x01402e98  length: 8
0x01402ea0  length: 8
0x01402ea8  length: 8
0x01402eb0  length: 8
0x01402eb8  length: 8
0x01403f80  length: 128
0x01404000  length: 128
0x01404080  length: 128
0x01404180  length: 128
0x01405800  length: 128
0x01405880  length: 128
0x01405900  length: 128
0x01405980  length: 128
0x01405a00  length: 128
0x01405a80  length: 128
0x01405b00  length: 128
0x01405b80  length: 128
Auxillary Map
--------------------------------------------------------
Extent 0     :  L1 dba:  0x01400768 Data dba:  0x0140076b
Extent 1     :  L1 dba:  0x01400768 Data dba:  0x01402f48
Extent 2     :  L1 dba:  0x01402f50 Data dba:  0x01402f51
Extent 3     :  L1 dba:  0x01402f50 Data dba:  0x01402f58
Extent 4     :  L1 dba:  0x01402f60 Data dba:  0x01402f61
Extent 5     :  L1 dba:  0x01402f60 Data dba:  0x01402f68
Extent 6     :  L1 dba:  0x01402f70 Data dba:  0x01402f71
Extent 7     :  L1 dba:  0x01402f70 Data dba:  0x01402f78
Extent 8     :  L1 dba:  0x01402e80 Data dba:  0x01402e81
Extent 9     :  L1 dba:  0x01402e80 Data dba:  0x01402e88
Extent 10    :  L1 dba:  0x01402e90 Data dba:  0x01402e91
Extent 11    :  L1 dba:  0x01402e90 Data dba:  0x01402e98
Extent 12    :  L1 dba:  0x01402ea0 Data dba:  0x01402ea1
Extent 13    :  L1 dba:  0x01402ea0 Data dba:  0x01402ea8
Extent 14    :  L1 dba:  0x01402eb0 Data dba:  0x01402eb1
Extent 15    :  L1 dba:  0x01402eb0 Data dba:  0x01402eb8
Extent 16    :  L1 dba:  0x01403f80 Data dba:  0x01403f82
Extent 17    :  L1 dba:  0x01404000 Data dba:  0x01404002
Extent 18    :  L1 dba:  0x01404080 Data dba:  0x01404082
Extent 19    :  L1 dba:  0x01404180 Data dba:  0x01404182
Extent 20    :  L1 dba:  0x01405800 Data dba:  0x01405802
Extent 21    :  L1 dba:  0x01405880 Data dba:  0x01405882
Extent 22    :  L1 dba:  0x01405900 Data dba:  0x01405902
Extent 23    :  L1 dba:  0x01405980 Data dba:  0x01405982
Extent 24    :  L1 dba:  0x01405a00 Data dba:  0x01405a02
Extent 25    :  L1 dba:  0x01405a80 Data dba:  0x01405a82
Extent 26    :  L1 dba:  0x01405b00 Data dba:  0x01405b02
Extent 27    :  L1 dba:  0x01405b80 Data dba:  0x01405b82
--------------------------------------------------------
Second Level Bitmap block DBAs
--------------------------------------------------------
DBA 1:   0x01400769

第二个问题：如何确认 truncate 释放的空间是否被覆盖，被哪些对象覆盖？
依据是用从 redo dump 找到的 truncate 前的 extent map 和 dba_extents 对比。如果有对象占用需要先 move 对象到其他表空间。如何从 redo dump 找到 extent map 请见后续段头块的 extent map 恢复。

具体恢复验证，请期待下一操作文章。

原文发布时间为：2018-08-02
本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”。