oracle中truncate数据恢复,oracle中truncate table后的数据恢复

前几天在工作中不小心truncate了一个表, 而该表中的数据又是很重要的数据。并且该表数据又没有备份的,有备份的也不是最新的,一时之间不知如何是好。在网上找了很多资料,但没有一个很适合的,有适合的但又没详细说明,很无奈。经过多方面的查找,以下是我综合网上的资料,成功恢复表数据的详细步骤,供大家参考。以便遇到同样的问题,可以很好的恢复。

1、首先odu数据恢复工具,然后解压。(odu工具见附件)

2、查询数据文件路径相关信息:select ts#,file#,rfile#,name,BLOCK_SIZE from v$datafile;

将其结构填入odu目录下的control.txt文件中

格式如下:

#ts #fno   #rfno     filename                                          block_size

0          1          1 /bbdata/hzdb/system01.dbf                                                              8192

1          2          2 /bbidx/hzdb/undotbs01.dbf                                                              8192

3          3          3 /bbidx/hzdb/indx01.dbf                                                                 8192

4          4          4 /bbdata/hzdb/tools01.dbf                                                               8192

5          5          5 /bbdata/hzdb/users01.dbf                                                               8192

6          6          6 /bbdata/hzdb/REPORT.dbf                                                                8192

7          7          7 /bbdata/hzdb/RESERVE.dbf                                                               8192

8          8          8 /bbdata/hzdb/WZHTBS.dbf                                                                8192

9          9          9 /bbdata/hzdb/perfstat01.dbf                                                            8192

3、打开oud

4、执行命令:unload dict

5、执行命令:scan extent (需等一会儿时间)

6、执行命令:desc [用户名].[被删除数据的表名]

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号块。

我们使用ODU来确定T1表原来的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块头,来得到表T1原来的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

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

7. 使用ODU来unload数据:

ODU> unload table test.t1 object 33547

8、使用sqlldr导入我们恢复的数据:打开cmd命令,执行E:\ODU\data>sqlldr 用户名/密码@数据库id control=TEST_T1.ctl

PRM DUL for oracle恢复被truncate截断掉的表 Oracle DBA神器:PRM灾难恢复工具,Schema级别数据恢复。PRM For Oracle Database – schema级别oracle数据数据恢复特性 ,PRM即ParnassusData Recovery Manager是企业级别Oracle数据库灾难恢复工具。PRM可以在无备份的情况下恢复被truncated/drop掉的表,也可以恢复无法打开的Oracle数据库(Alter Database Open失败)中的数据。 PRM是图形化增强版的Oracle DUL工具,同时具备很多Oracle DUL不具备的特性 情况 当某张表被意外truncated掉了,需要恢复其上的所有数据时。表空间的多个数据文件均存放在ASM上,且没有任何形式的备份。 注意这边文章针对的是PRM在 数据字典模式下的Truncate恢复选项不可用时使用,数据字典模式下的Truncate恢复选项是最简单、易用的一种模式,具体使用见《使用PRM恢复Oracle数据库中误truncate截断的表数据》http://www.parnassusdata.com/zh-hans/node/52 PRM 3.0的下载地址: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3002.zip PRM 的官方网站: http://www.parnassusdata.com/ PRM背景 PRM恢复表数据时存在多种模式, PRM需要知道哪些表上的数据块是需要被读取并取出数据的。默认的表现形式是直接从segment header数据段头里获取EXTENT MAP即盘区图,另一种方案就是由PRM自己去构建一个盘区图。 这些盘区图可以通过,PRM的SCAN DATABASE选项来获得: Recovery Wizard => Non-Dictionary Mode,如果是ASM则选择Non-Dictionary Mode(ASM) 执行SCAN Database后会生成SEG$和EXT$的数据到PRM内嵌的数据库中,之后可以选择SCAN TABLES FROM SEGMENTS 或者 SCAN TABLES FROM EXTENTS。 FROM Segments 意味着使用Segment Header中获得的Extent MAP信息,而FROM Extents意味着使用PRM自己扫描获得的EXTENT信息。 请注意当TRUNCATE发生后, 数据Table的Segment Header中的Extent MAP信息就会被清空了, 但实际存放数据数据块中的行数据还是在哪里的,除非被其他数据表/索引的增长而覆盖了。 所以当Truncate发生后选择SCAN TABLES FROM SEGMENT 是找不回数据的,必须使用SCAN TABLES FROM EXTENTS, EXTENT的信息是PRM自己去数据文件中扫描获得的,所以只要有数据的地方PRM就会自己去找到。 除了Truncate需要使用到 SCAN TABLES FROM EXTENTS之外对于DROP TABLE的恢复也可以用到SCAN TABLES FROM EXTENTS , 总之当Segment Header找不到(可能存放Segment Header的数据文件丢失了)、或者已损坏(可能Segment Header的数据块被损坏了)、或者其中的Extent Map数据无效(Truncate、DROP或逻辑损坏)时都可以使用SCAN TABLES FROM EXTENTS 。 但是如果不存在上述的问题时,建议用SCAN TABLES FROM SEGMENTS ,因为从Segment Header获取信息更方便也更高效一些。 在PRM中同一个程序实例 同时只能使用SCAN TABLES FROM SEGMENTS 或者 SCAN TABLES FROM EXTENTS 中的一个。 使用SCAN TABLES FROM EXTENTS 后需要找到对应被TRUNCATE掉的表的原始DATA_OBJECT_ID,即左侧属性图中的一个对象,并将其DataBridge 数据搭桥传输到目标数据库中即可。 用户truncate误删 schema下的若干数据表,无法使用flashback query等技术恢复数据,尝试从之前的全备份中恢复,数据库restore速度较快,但是archivelog恢复时由于HP data Protecter的不明原因导致归档恢复十分缓慢,缓慢一个归档往往要几分钟,而需要restore数百个归档,时间上无法接受。 该案例通过PRM-DUL直接在字典模式下恢复truncate数据的功能,在不到一个小时内就恢复了数十万条数据,虽然我们无法保证不丢失一条数据,但至少帮助用户在最短时间内恢复了主要业务。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值