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

  1. 云栖社区>
  2. 数据和云>
  3. 博客>
  4. 正文

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

技术小能手 2018-08-03 10:18:00 浏览1533
展开阅读全文

摘要


众所周知,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                              1898
 
SYS@:>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
本文来自云栖社区合作伙伴“数据和云”,了解相关信息可以关注“数据和云”。

网友评论

登录后评论
0/500
评论
技术小能手
+ 关注
所属团队号: 数据和云