使用ODU恢复Truncate表ODUmanual ODU3月 15th, 2009
意外Truncate表的事情时有发生,ODU提供了方便的恢复Truncate表的功能。被Truncate的表,只要原来的空间没有被重用(即数据被覆盖),则数据都是可以恢复的。
如果发现一个表被意外地Truncate,而需要马上恢复。首先要做的就是关闭数据库,或者OFFLINE那个表所在的表空间,或者关闭所有应用。目的只有一个,确保空间不会被重用,数据不会被覆盖。
下面举例说明如何用ODU恢复被Truncate掉的表。
1. 建立测试的表DB_JJ_INFO_TEMP。
SQL> connect pdata/test
已连接。
SQL> create table DB_JJ_INFO_TEMP as select * from dba_objects;
SQL> truncate table DB_JJ_INFO_TEMP;
2. 我们OFFLINE掉DB_JJ_INFO_TEMP表的表空间(实际上在实际的系统中,如果有比较多的活动,则表空间不容易被OFFLINE下来)。然后做一个Checkpoint,让ODU能够读到最新的数据字典数据。
SQL> select tablespace_name from user_tables where table_name='DB_JJ_INFO_TEMP';
TABLESPACE_NAME
------------------------------
PDATA
SQL> alter tablespace PDATA offline;
表空间已更改。
SQL> alter system checkpoint;
系统已更改。
22=================================完善字典文件格式如下
control.txt文件中的数据格式为:
表空间号 文件号 相对文件号 文件名 块大小 是否大文件表空间
每列之间用空白分隔,可以只需要前四列,即块大小和是否大文件表空间可省略,块大小省略时,数据文件的默认块大小为config.txt中block_size的大小。下面是一个示例的数据:
#ts #fno #rfno filename block_size bigfile
0 1 1 D:\ORACLE\ORADATA\XJ\SYSTEM01.DBF 4096
1 2 2 D:\ORACLE\ORADATA\XJ\UNDOTBS01.DBF 4096
3 3 3 D:\ORACLE\ORADATA\XJ\DRSYS01.DBF 4096
4 4 4 D:\ORACLE\ORADATA\XJ\EXAMPLE01.DBF 4096
5 5 5 D:\ORACLE\ORADATA\XJ\INDX01.DBF 4096
6 6 6 D:\ORACLE\ORADATA\XJ\ODM01.DBF 4096
7 7 7 D:\ORACLE\ORADATA\XJ\TOOLS03.DBF 4096
7 8 8 D:\ORACLE\ORADATA\XJ\TOOLS02.DBF 4096
9 9 9 D:\ORACLE\ORADATA\XJ\XDB01.DBF 4096
11 10 10 D:\ORACLE\ORADATA\XJ\TEST01.DBF 2048
14 11 11 D:\ORACLE\ORADATA\XJ\K16.DBF 16384
如果数据文件头是完好的,则ODU会自动从文件头里面获取表空间号,文件号,相对文件号,文件块大小等。表空间号,文件号和相对文件号可以写为0。
注意:ODU将检查control.txt文件中的第一个数据文件是否为SYSTEM表空间文件,所以要将SYSTEM表空间的第1个文件放在control.txt文件中的第一行。否则将不能自动获得数据字典数据。
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. 获取PDATA用户下的DB_JJ_INFO_TEMP表,也就是我们要恢复的表的信息:
ODU> desc PDATA.DB_JJ_INFO_TEMP
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)
从上面的输出中,我们可以看到,PDATA.DB_JJ_INFO_TEMP表所在的表空间号为11,数据段头部为10号文件的1400号块。
5. 接下来用ODU扫描表空间的extent:
ODU> scan extent tablespace 11
scanning extent…
scanning extent finished.
6. 我们使用ODU来确定DB_JJ_INFO_TEMP表原来的data object id。一般来说,数据段的数据块,一般是在段头后面相邻的块中。但是我们可以从段头来确认:
ODU> dump datafile 10 block 1400
Block Header:
block type=0×23 (ASSM segment header block)
block format=0×02 (oracle 8 or 9)
block rdba=0×02800578 (file#=10, block#=1400)
scn=0×0000.00286f2d, seq=4, tail=0×6f2d2304
block checksum value=0×0=0, flag=0
Data Segment Header:
Extent Control Header
-------------------------------------------------------------
Extent Header:: extents: 1 blocks: 5
last map: 0×00000000 #maps: 0 offset: 668
Highwater:: 0×02800579 (rfile#=10,block#=1401)
ext#: 0 blk#: 3 ext size:5
#blocks in seg. hdr’s freelists: 0
#blocks below: 0
mapblk: 0×00000000 offset: 0
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0×02800579 ext#: 0 blk#: 3 ext size: 5
#blocks in seg. hdr’s freelists: 0
#blocks below: 0
mapblk 0×00000000 offset: 0
Level 1 BMB for High HWM block: 0×02800576
Level 1 BMB for Low HWM block: 0×02800576
--------------------------------------------------------
Segment Type: 1 nl2: 1 blksz: 2048 fbsz: 0
L2 Array start offset: 0×00000434
First Level 3 BMB: 0×00000000
L2 Hint for inserts: 0×02800577
Last Level 1 BMB: 0×02800576
Last Level 1I BMB: 0×02800577
Last Level 1II BMB: 0×00000000
Map Header:: next 0×00000000 #extents: 1 obj#: 33549 flag: 0×220000000
Extent Map
-------------------------------------------------------------
0×02800576 length: 5
Auxillary Map
-------------------------------------------------------------
Extent 0 : L1 dba: 0×02800576 Data dba: 0×02800579
-------------------------------------------------------------
Second Level Bitmap block DBAs
-------------------------------------------------------------
DBA 1: 0×02800577
从上面的输出中的“Extent 0 : L1 dba: 0×02800576 Data dba: 0×02800579”可以看到,段的第1个数据块的RDBA为0×02800579,也就是10号文件的1401块。
我们dump第10号文件的1401块头,来得到表DB_JJ_INFO_TEMP原来的data object id:
ODU> dump datafile 10 block 1401 header
Block Header:
block type=0×06 (table/index/cluster segment data block)
block format=0×02 (oracle 8 or 9)
block rdba=0×02800579 (file#=10, block#=1401)
scn=0×0000.00285f2b, seq=2, tail=0×5f2b0602
block checksum value=0×0=0, flag=0
Data Block Header Dump:
Object id on Block? Y
seg/obj: 0×830b=33547 csc: 0×00.285f21 itc: 3 flg: E typ: 1 (data)
brn: 0 bdba: 0×2800576 ver: 0×01
Itl Xid Uba Flag Lck Scn/Fsc
0×01 0xffff.000.00000000 0×00000000.0000.00 C--- 0 scn 0×0000.00285f21
0×02 0×0000.000.00000000 0×00000000.0000.00 ---- 0 fsc 0×0000.00000000
0×03 0×0000.000.00000000 0×00000000.0000.00 ---- 0 fsc 0×0000.00000000
Data Block Dump:
================
flag=0×0 --------
ntab=1
nrow=16
frre=-1
fsbo=0×32
ffeo=0×145
avsp=0×113
tosp=0×113
可以看到,DB_JJ_INFO_TEMP表原来的data object id就是33547。
7. 使用ODU来unload数据:
ODU> unload table PDATA.DB_JJ_INFO_TEMP object 33547
Unloading table: DB_JJ_INFO_TEMP,object ID: 33547
Unloading segment,storage(Obj#=33547 DataObj#=33547 TS#=11 File#=10 Block#=1400 Cluster=0)
8. 使用sqlplus将PDATA表空间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 DB_JJ_INFO_TEMP;
可以看到,数据已经完全恢复。