首页 > oracle知识 > oracle备份 >

oracle truncate table recover(oracle 如何拯救误操作truncate的表)

作者: 初见博客 分类: oracle备份 发布时间: 2022-09-29 01:43

生产上肯定是容易脑袋发热,truncate一张表,立马的心跳加速,眼神也不迷糊了,搞错了,完了……

那么,truncate表后,能不能进行恢复?

truncate操作是比较危险的操作,不记录redo,也不能通过闪回查询来找回数据,但是只要段所占用的块没有全部被重新占用的情况下,我们还是可以通过一些特殊的办法来找回truncate掉的数据,因为当Truncate命令发起之后,Oracle实际上并没有在删除底层数据块上的数据,而是要等到重用的时候才会把这一部分数据回收,于是这给了我们一个能够恢复数据库的机会。

所以当truncate 表后,需要立马的进行恢复,当尤其是生产上表空间不太够的情况,或者是业务比较繁忙的情况,不一定能够完全恢复truncate表的数据,所以时间就是金钱,理论上也不太可能把业务数据的表空间设置成read only状态,所以,尽快进行恢复操作;

 

1.ORACLE官方上是dul能够进行数据抽取

DUL 是Data Unloader 的缩写,是一个荷兰的Oracle 工程师开发的,他的名字为Bernard Van Duijnen。DUL 是一个C 开发的小程序,编译后整个程序只有一个文件,大小也不过几百 KB,它工作时不需 Oracle RDBMS 以及任何的Oracle 的程序、组件,它可以直接从一个坏了数据库的数据文件中读取数据,生成IMP 或SQL*Loader 可以识别的文件。

DUL 不是一个商用化的产品,Oracle 不卖、不提供也不支持它的使用。DUL 只有在Oracle 的内部网站才可以下载到,因此也只有Oracle 的Supporter 才能下载到有这个工具。

 

2.FY_Recover_Data.zip 存储过程恢复

如果我们已经有一套元数据及数据块,然后将被TRUNCATE的用户数据块的内容取代其用户数据块的内容,是否可以“骗”过Oracle,让它读出这些数据呢?

回顾一下表扫描的过程,这个方法应该是可行的。我们只要想办法构造出一个结构相同、且具有完整元数据信息和格式化了的用户数据块的傀儡表对象,然后将被TRUNCATE的用户数据块找出,再将其数据内容部分嫁接到傀儡对象的用户数据块,使Oracle以外这是傀儡对象的数据,就能让Oracle扫描并读出数据内容。其原理用图示描述如下:

1339563-20201103135401894-1698734022

 

 

下载地址:

 

http://www.hellodba.com/Download/FY_Recover_Data.zip

 

3.gDUL(这个后面再做测试)

  • 完整支持多种格式导出,包括expdp,exp,text格式。目前市面上的类dul工具只有gDUL支持expdp格式。
  • 支持ASM文件系统,并内置asmcmd命令。
  • 支持绝大多数列类型,支持常见的NUMBER,CHAR, VARCHAR2, DATE,LOB, LONG等类型。
  • 支持主流硬件平台(HP-UX,AIX, Solaris, Linux, Windows),各个平台仅需单一的可执行文件,方便分发。
  • 重点是——永久免费使用,无需额外费用,不开源。

gdul完全就是破解了dul,两者想差不大,底层原理都一样,下载地址:https://pan.baidu.com/s/1c1yrbkW#list/path=%2F

4.其他收费的数据抽取的工具就多了,比如odl,PRM-DUL,AUL/mydul

 

FY_Recover_Data.pck恢复truncate的表

 

可以参考案例:

http://www.hellodba.com/reader.php?ID=190&lang=CN

环境:oracle 19c

linux 7.6

恢复要求:FY_Recover_Data.pck支持windows和linux truncate表操作,

1.oracle有完整元数据信息,系统表空间不能有问题。

2.执行的时候需要有dba权限的用户执行(最好是sys用户,如果发现包状态异常,那就是权限过小,不能访问一些视图和系统表)

3.大写(作者没有整合大小写,恢复的时候,输入的对象名和用户都是要大写)

4.linux测试完恢复(tmp下有表空间的数据文件,如果不用的话,建议删除fy_rec_Data,fy_rst_data)表空间,不然服务器重启,数据库起不起来(临时文件被清理了)

 

create table TEST_OBJ as select * from dba_objects;

insert into  TEST_OBJ  select * from dba_objects;

insert into  TEST_OBJ  select * from dba_objects;

insert into  TEST_OBJ  select * from TEST_OBJ ;

commit;

1339563-20201103143437724-2088697589

 

 

 

 

查看这个包:

tow表示需要恢复的表的所有者(本次测试为SYS),ttb为表的名称,fbks表示恢复表中要填写的块号(可选也可不填),后面临时表空间,和离线文件都默认为空;

1339563-20201103143615079-258237235

truncate table TEST_OBJ ;

进行恢复。

在执行的时候,查看登陆用户有没有权限:

select  count(*) from sys.user$; select  count(*) from sys.tab$;  –如果查看不了这些视图,说明用户权限不够,建议用sys,system或者具有dba权限用户彩操作。

 

我是用plsql develop

打开FY_Recover_Data包,执行里面的存储过程recover_truncated_table;

plsql 命令行执行:exec fy_recover_data.recover_truncated_table(‘SYS’,’TEST_OBJ’);

1339563-20200929140706506-784515805

记住了,一定要是大写,表名和用户名.

14:01:05: Use existing Directory Name: FY_DATA_DIR
14:01:05: Recover Table: SYS.TEST_OBJ$
14:01:05: Restore Table: SYS.TEST_OBJ$$
14:01:09: Copy file of Recover Tablespace: FY_REC_DATA_COPY.DAT
14:01:09: begin to recover table SYS.TEST_OBJ
14:01:09: Use existing Directory Name: TMP_HF_DIR
14:01:09: Recovering data in datafile /u01/app/oracle/oradata/TEST19C/datafile/o1_mf_system_hnz0bpfm_.dbf
14:01:09: Use existing Directory Name: TMP_HF_DIR
14:04:07: 15550 truncated data blocks found.
14:04:07: 919872 records recovered in backup table SYS.TEST_OBJ$$
14:04:07: Total: 15550 truncated data blocks found.
14:04:07: Total: 919872 records recovered in backup table SYS.TEST_OBJ$$
14:04:07: Recovery completed.
14:04:07: Data has been recovered to SYS.TEST_OBJ$$

恢复出来了,如果被truncate表数据量很大,恢复时间比较久。

1339563-20200929140741938-1140597055

insert into TEST_OBJ select * from SYS.TEST_OBJ$$;

commit;

1339563-20201103144823544-1709868626

 

 

 

tmp下有表空间的数据文件,如果用完了的话,建议删除fy_rec_Data,fy_rst_data表空间。

1339563-20201016184452507-1575256619

drop tablespace fy_rec_data including contents and datafiles;

drop tablespace fy_rst_data including contents and datafiles;

下次需要恢复的时候建两个表空间就好了。

 

发表回复

您的电子邮箱地址不会被公开。