使用ODU恢复Truncate表

意外Truncate表的事情时有发生,ODU提供了方便的恢复Truncate表的功能。被Truncate的表,只要原来的空间没有被重用(即数据被覆盖),则数据都是可以恢复的。

如果发现一个表被意外地Truncate,而需要马上恢复。首先要做的就是关闭数据库,或者OFFLINE那个表所在的表空间,或者关闭所有应用。目的只有一个,确保空间不会被重用,数据不会被覆盖。

下面举例说明如何用ODU恢复被Truncate掉的表。

1. 建立两个测试的表T1和T2,这两个表的数据完全一样。建两个数据完全一样的表的目的在于方便在恢复后对比数据。

SQL> connect test/test
已连接。

SQL> create table t1 as select * from dba_objects;

表已创建。

SQL> create table t2 as select * from t1;

表已创建。

SQL> truncate table t1;

表已截掉。

2. 我们OFFLINE掉T1表的表空间(实际上在实际的系统中,如果有比较多的活动,则表空间不容易被OFFLINE下来)。然后做一个Checkpoint,让ODU能够读到最新的数据字典数据。

SQL> select tablespace_name from user_tables where table_name='T1';

TABLESPACE_NAME
------------------------------
TEST

SQL> alter tablespace test offline;

表空间已更改。
SQL> alter system checkpoint;

系统已更改。

3. 运行ODU,并unload数据字典。

ODU> unload dict
get_bootstrap_dba: compat header size:12
CLUSTER C_USER# file_no: 1 block_no: 177
TABLE OBJ$ file_no: 1 block_no: 241
CLUSTER C_OBJ# file_no: 1 block_no: 49
CLUSTER C_OBJ# file_no: 1 block_no: 49
found IND$'s obj# 19
found IND$'s dataobj#:2,ts#:0,file#:1,block#:49,tab#:3
found TABPART$'s obj# 230
found TABPART$'s dataobj#:230,ts#:0,file#:1,block#:3313,tab#:0
found INDPART$'s obj# 234
found INDPART$'s dataobj#:234,ts#:0,file#:1,block#:3377,tab#:0
found TABSUBPART$'s obj# 240
found TABSUBPART$'s dataobj#:240,ts#:0,file#:1,block#:3473,tab#:0
found INDSUBPART$'s obj# 245
found INDSUBPART$'s dataobj#:245,ts#:0,file#:1,block#:3553,tab#:0
found IND$'s obj# 19
found IND$'s dataobj#:2,ts#:0,file#:1,block#:49,tab#:3
found LOB$'s obj# 156
found LOB$'s dataobj#:2,ts#:0,file#:1,block#:49,tab#:6
found LOBFRAG$'s obj# 258
found LOBFRAG$'s dataobj#:258,ts#:0,file#:1,block#:3761,tab#:0


4. 获取TEST用户下的T1表,也就是我们要恢复的表的信息:

ODU> desc test.t1

Object ID:33547
Storage(Obj#=33547 DataObj#=33549 TS#=11 File#=10 Block#=1400 Cluster=0)

NO. SEG INT Column Name                    Null?     Type
--- --- --- ------------------------------ --------- ------------------------------
  1   1   1 OWNER                                    VARCHAR2(30)
  2   2   2 OBJECT_NAME                              VARCHAR2(128)
  3   3   3 SUBOBJECT_NAME                           VARCHAR2(30)
  4   4   4 OBJECT_ID                                NUMBER
  5   5   5 DATA_OBJECT_ID                           NUMBER
  6   6   6 OBJECT_TYPE                              VARCHAR2(18)
  7   7   7 CREATED                                  DATE
  8   8   8 LAST_DDL_TIME                            DATE
  9   9   9 TIMESTAMP                                VARCHAR2(19)
 10  10  10 STATUS                                   VARCHAR2(7)
 11  11  11 TEMPORARY                                VARCHAR2(1)
 12  12  12 GENERATED                                VARCHAR2(1)
 13  13  13 SECONDARY                                VARCHAR2(1)

从上面的输出中,我们可以看到,TEST.T1表所在的表空间号为11,数据段头部为10号文件的1400号块。

5. 接下来用ODU扫描表空间的extent:

ODU> scan extent tablespace 11

scanning extent...
scanning extent finished.

6. 我们使用ODU来确定T1表原来的data object id。一般来说,数据段的数据块,一般是在段头后面相邻的块中。但是我们可以从段头来确认:

ODU> dump datafile 10 block 1400
Block Header:
block type=0x23 (ASSM segment header block)
block format=0x02 (oracle 8 or 9)
block rdba=0x02800578 (file#=10, block#=1400)
scn=0x0000.00286f2d, seq=4, tail=0x6f2d2304
block checksum value=0x0=0, flag=0
Data Segment Header:
  Extent Control Header
  -------------------------------------------------------------
  Extent Header:: extents: 1  blocks: 5
                  last map: 0x00000000  #maps: 0  offset: 668
      Highwater:: 0x02800579  (rfile#=10,block#=1401)
                  ext#: 0  blk#: 3   ext size:5
      #blocks in seg. hdr's freelists: 0
      #blocks below: 0
      mapblk: 0x00000000   offset: 0
  --------------------------------------------------------
  Low HighWater Mark :
      Highwater::  0x02800579  ext#: 0      blk#: 3      ext size: 5
  #blocks in seg. hdr's freelists: 0
  #blocks below: 0
  mapblk  0x00000000  offset: 0
  Level 1 BMB for High HWM block: 0x02800576
  Level 1 BMB for Low HWM block: 0x02800576
  --------------------------------------------------------
  Segment Type: 1 nl2: 1      blksz: 2048   fbsz: 0
  L2 Array start offset:  0x00000434
  First Level 3 BMB:  0x00000000
  L2 Hint for inserts:  0x02800577
  Last Level 1 BMB:  0x02800576
  Last Level 1I BMB:  0x02800577
  Last Level 1II BMB:  0x00000000
     Map Header:: next  0x00000000  #extents: 1    obj#: 33549  flag: 0x220000000
  Extent Map
  -------------------------------------------------------------
   0x02800576  length: 5

  Auxillary Map
  -------------------------------------------------------------
   Extent 0      :  L1 dba:  0x02800576 Data dba:  0x02800579
  -------------------------------------------------------------

   Second Level Bitmap block DBAs
  -------------------------------------------------------------
   DBA 1:   0x02800577

从上面的输出中的“Extent 0      :  L1 dba:  0×02800576 Data dba:  0×02800579”可以看到,段的第1个数据块的RDBA为0x02800579,也就是10号文件的1401块。

我们dump第10号文件的1401块头,来得到表T1原来的data object id:

ODU> dump datafile 10 block 1401 header
Block Header:
block type=0x06 (table/index/cluster segment data block)
block format=0x02 (oracle 8 or 9)
block rdba=0x02800579 (file#=10, block#=1401)
scn=0x0000.00285f2b, seq=2, tail=0x5f2b0602
block checksum value=0x0=0, flag=0
Data Block Header Dump:
 Object id on Block? Y
 seg/obj: 0x830b=33547  csc: 0x00.285f21  itc: 3  flg: E  typ: 1 (data)
     brn: 0  bdba: 0x2800576 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00285f21
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
Data Block Dump:
================
flag=0x0 --------
ntab=1
nrow=16
frre=-1
fsbo=0x32
ffeo=0x145
avsp=0x113
tosp=0x113

可以看到,T1表原来的data object id就是33547

7. 使用ODU来unload数据:

ODU> unload table test.t1 object 33547

Unloading table: T1,object ID: 33547
Unloading segment,storage(Obj#=33547 DataObj#=33547 TS#=11 File#=10 Block#=1400 Cluster=0)

8. 使用sqlplus将TEST表空间ONLINE:

SQL> alter tablespace test online;

表空间已更改。

9. 使用sqlldr导入我们恢复的数据:

E:\ODU\data>sqlldr test/test control=TEST_T1.ctl

SQL*Loader: Release 9.2.0.8.0 - Production on 星期日 3月 15 15:13:56 2009

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

达到提交点,逻辑记录计数6502
达到提交点,逻辑记录计数13004
达到提交点,逻辑记录计数19506
达到提交点,逻辑记录计数26008
达到提交点,逻辑记录计数30071

至此,恢复数据的步骤已经完成。我们来对比一下数据,看看数据是否和被Truncate前的数据完全一样:

SQL> select * from t2 minus select * from t1;

未选定行

SQL> select * from t1 minus select * from t2;

未选定行

可以看到,数据已经完全恢复。

UPDATE :
从3.0.7版本开始,对truncate table的支持更方便。可能不用人工去找到原来的data object id,而支持使用:

unload table username.tablename object auto

ODU自动探测truncate之前的data object id,对分区表同样适用。

,
Trackback

22 comments untill now

  1. 2.5.2已经发布了,刚刚才看到,等了很久了:)

  2. 建议在unload table成功之后显示共unload了多少条数据。类似于dul这样的。
    DUL> unload table t2 (object_id number) storage (dataobjno 25551);
    . unloading table T2 16450 rows unloaded

    老熊 Reply:

    谢谢你的建议,我会加上这个功能。

    老熊 Reply:

    新发布的3.0.1版已经增加了此项功能。

  3. 呵呵,厉害,一个小时就发布新版了。。。

  4. cityvigil @ 2009-05-20 20:45

    马上拿来,做了两个实验,真爽!
    牛!

  5. guyuanli @ 2009-07-20 17:26

    请问老熊在第四步中
    ODU> desc test.t1
    Object ID:33547
    Storage(Obj#=33547 DataObj#=33549 TS#=11 File#=10 Block#=1400 Cluster=0)
    已经查到了对象ID
    第七步可以直接应用么?

    老熊 Reply:

    @guyuanli, 不能,因为那个是obj#,显示的dataobj#也是最新的,不是TRUNCATE之前的。

    使用最新的3.0.7以上的版本吧。unload table xxx object auto就可以了。

  6. 今天帮开发恢复truncate的一个配置表.
    非常感谢!

  7. 卫生棉条 @ 2009-10-25 11:30

    哈哈,非常感谢老熊!

  8. 请问老熊
    unload table username.tablename object auto
    命令不成功,
    unload object object_id tablespace ts# column NUMBER NUMBER NUMBER
    却成功了
    是何原因啊?

    ODU> desc zhao.tmp_check2

    Object ID:58120
    Storage(Obj#=58120 DataObj#=58120 TS#=49 File#=4 Block#=773129 Cluster=0)

    NO. SEG INT Column Name Null? Type

    — — — —————————— ——— —————————

    1 1 1 BILL_REF_NO NOT NULL NUMBER(10)

    2 2 2 BILL_INVOICE_ROW NUMBER

    3 3 3 FEE NUMBER

    ODU> unload table zhao.tmp_check2 object auto
    Auto mode truncated table.

    Unloading table: TMP_CHECK2,object ID: 58120
    Unloading segment,storage(Obj#=58120 DataObj#=58120 TS#=49 File#=4 Block#=773129
    Cluster=0)
    0 rows unloaded

    ODU> unload object 58120 sample

    Unloading Object,object ID: 58120, Cluster: 0
    output data is in file : ‘data\ODU_0000058120.txt’

    Sample result:
    object id: 58120
    tablespace no: 49
    sampled 1073 rows
    column count: 3
    column 1 type: NUMBER
    column 2 type: NUMBER
    column 3 type: NUMBER

    COMMAND:
    unload object 58120 tablespace 49 column NUMBER NUMBER NUMBER

    ODU> unload object 58120 tablespace 49 column NUMBER NUMBER NUMBER

    Unloading Object,object ID: 58120, Cluster: 0
    292787 rows unloaded

    老熊 Reply:

    @anjidx,
    unload table object auto命令通常是恢复truncate表用的,这种情况下我们需要的是实际数据中的data object id与数据字典中的data object id不同。而你测试这个则是相同的。

  9. 我这里试着不能恢复被truncate的数据啊,,麻烦指教!@

  10. 在linux-3.08版本,
    之前的方式,可以找出数据
    ODU> unload table test.t2 object 52459

    Unloading table: T2,object ID: 52459
    Unloading segment,storage(Obj#=52459 DataObj#=52459 TS#=4 File#=4 Block#=110035 Cluster=0)
    4399 rows unloaded

    自动方式,不能恢复数据,object id是找出52459
    ODU> unload table test.t2 object auto
    Auto mode truncated table.

    Unloading table: T2,object ID: 52459
    Unloading segment,storage(Obj#=52459 DataObj#=52459 TS#=4 File#=4 Block#=110035 Cluster=0)
    0 rows unloaded

    这是什么情况

  11. 問下下,有一點不明白。你文中提到的“段的第1个数据块的RDBA为0×02800579,也就是10号文件的1401块。”
    1401這個數字是通過0×02800579來轉換出來的嗎?是怎麼轉換的?
    現在這裡測試
    ODU> dump datafile 20 block 11
    Extent 0 : L1 dba: 0x05000009 Data dba: 0x0500000c
    那該是第几块?

  12. 应该是根据这个起始地址来算对吧
    1400是
    block rdba=0×02800578 (file#=10, block#=1400)
    然后再通过dump 1401查看
    block rdba=0×02800579 (file#=10, block#=1401)

    老熊 Reply:

    @muyu208, 可以通过
    DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK

    DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE
    来转换。

  13. 感谢老兄 我不我就死翘翘了

  14. 您好:
    我有几个问题请教
    1、我下载的是现在最新的413的版本,没有unload table xxx object auto的功能呢?
    2、恢复truncate的表
    1)用两种恢复truncate的方法恢复都不完整,数据不全
    2)用unload table object 这个方法恢复的时候
    ODU> desc wn.t1

    Object ID:59986
    Storage(Obj#=59986 DataObj#=59987 TS#=4 File#=4 Block#=19 Cluster=0)

    NO. SEG INT Column Name Null? Type
    — — — —————————— ——— ——————————
    1 1 1 OWNER VARCHAR2(30)
    2 2 2 OBJECT_NAME VARCHAR2(128)
    3 3 3 SUBOBJECT_NAME VARCHAR2(30)
    4 4 4 OBJECT_ID NUMBER
    5 5 5 DATA_OBJECT_ID NUMBER
    6 6 6 OBJECT_TYPE VARCHAR2(19)
    7 7 7 CREATED DATE
    8 8 8 LAST_DDL_TIME DATE
    9 9 9 TIMESTAMP VARCHAR2(19)
    10 10 10 STATUS VARCHAR2(7)
    11 11 11 TEMPORARY VARCHAR2(1)
    12 12 12 GENERATED VARCHAR2(1)
    13 13 13 SECONDARY VARCHAR2(1)

    ODU> scan extent tablespace 4

    scan extent start: 2013-02-19 16:27:53
    scanning extent…
    scanning extent finished.
    scan extent completed: 2013-02-19 16:27:54

    ODU> dump datafile 4 block 19
    Block Header:
    block type=0x23 (ASSM segment header block)
    block format=0xa2 (oracle 10+)
    block rdba=0x01000013 (file#=4, block#=19)
    scn=0x0000.0050266a, seq=3, tail=0x266a2303
    block checksum value=0x4718=18200, flag=4
    Data Segment Header:
    Extent Control Header
    ————————————————————-
    Extent Header:: extents: 1 blocks: 8
    last map: 0x00000000 #maps: 0 offset: 2716
    Highwater:: 0x01000014 (rfile#=4,block#=20)
    ext#: 0 blk#: 3 ext size:8
    #blocks in seg. hdr’s freelists: 0
    #blocks below: 0
    mapblk: 0x00000000 offset: 0
    ——————————————————–
    Low HighWater Mark :
    Highwater:: 0x01000014 ext#: 0 blk#: 3 ext size: 8
    #blocks in seg. hdr’s freelists: 0
    #blocks below: 0
    mapblk 0x00000000 offset: 0
    Level 1 BMB for High HWM block: 0x01000011
    Level 1 BMB for Low HWM block: 0x01000011
    ——————————————————–
    Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
    L2 Array start offset: 0x00001434
    First Level 3 BMB: 0x00000000
    L2 Hint for inserts: 0x01000012
    Last Level 1 BMB: 0x01000011
    Last Level 1I BMB: 0x01000012
    Last Level 1II BMB: 0x00000000
    Map Header:: next 0x00000000 #extents: 1 obj#: 59990 flag: 0x210000000
    Extent Map
    ————————————————————-
    0x01000011 length: 8

    Auxillary Map
    ————————————————————-
    Extent 0 : L1 dba: 0x01000011 Data dba: 0x01000014
    ————————————————————-

    Second Level Bitmap block DBAs
    ————————————————————-
    DBA 1: 0x01000012

    ODU> dump datafile 4 blocka 20 header
    dump datafile block [header]
    ODU> dump datafile 4 block 20 header
    Block Header:
    block type=0x06 (table/index/cluster segment data block)
    block format=0xa2 (oracle 10+)
    block rdba=0x01000014 (file#=4, block#=20)
    scn=0x0000.005025cd, seq=1, tail=0x25cd0601
    block checksum value=0x6511=25873, flag=4
    Data Block Header Dump:
    Object id on Block? Y
    seg/obj: 0xea55=59989 csc: 0x00.5025c9 itc: 3 flg: E typ: 1 (data)
    brn: 0 bdba: 0x1000011 ver: 0x01

    Itl Xid Uba Flag Lck Scn/Fsc
    0x01 0xffff.000.00000000 0x00000000.0000.00 C— 0 scn 0x0000.005025c9
    0x02 0x0000.000.00000000 0x00000000.0000.00 —- 0 fsc 0x0000.00000000
    0x03 0x0000.000.00000000 0x00000000.0000.00 —- 0 fsc 0x0000.00000000
    Data Block Dump:
    ================
    flag=0x0 ——–
    ntab=1
    nrow=91
    frre=-1
    fsbo=0xc8
    ffeo=0x432
    avsp=0x36a
    tosp=0x36a

    ODU> unload table wn.t1 object 59989

    Unloading table: T1,object ID: 59989
    Unloading segment,storage(Obj#=59989 DataObj#=59989 TS#=4 File#=4 Block#=19 Cluster=0)
    689 rows unloaded

    直到之这一步恢复了只有689行数据,表示按照dba_objects创建的表,并且
    在data目录下生成的并不是对应的T1表的文件,而是ODU_0000059989.ctl ODU_0000059989.sql ODU_0000059989.txt这三个文件,控制文件里也是ODU_0000059989对象,并不是T1
    请教这几个问题

    老熊 Reply:

    1. 语法有所变化:
    unload table object truncate
    2. 试用版只能恢复部分数据。

    至于用unload table object恢复出来的数据的文件名,这是有其特殊的地方,程序是这样的。因为一个表可能会有多个object id,比如分区表。

  15. 太牛逼了,搞了半个小时就好了 救了我一命啊

  16. wmy102125 @ 2015-08-20 20:08

    老熊,你现在还回复这个帖子么?
    遇到个很郁闷的问题,比较紧急,我前面的步骤都是按照你的步骤来的,最后一步将回复回来的数据导入到数据库中就不停的在报错

    我看了我生成文件的名称是:
    ODU_0000074585.ctl
    ODU_0000074585.sql
    ODU_0000074585.txt

    文件ODU_0000074585.txt中有恢复的数据,但是导入到数据库的时候,就找不到生成表的对象,来来回回弄了好多遍都是这个结果

    D:\exsits\OracleReback\odu_309_win32\odu\data>sqlldr SCOTT/orcl control= ODU_0000074585.ctl

    SQL*Loader: Release 11.2.0.1.0 – Production on 星期四 8月 20 20:06:40 2015

    Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

    SQL*Loader-941: 在描述表 “ODU_0000074585″ 时出错
    ORA-04043: 对象 “ODU_0000074585″ 不存在

Add your comment now