生产上肯定是容易脑袋发热,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扫描并读出数据内容。其原理用图示描述如下:
下载地址:
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;
查看这个包:
tow表示需要恢复的表的所有者(本次测试为SYS),ttb为表的名称,fbks表示恢复表中要填写的块号(可选也可不填),后面临时表空间,和离线文件都默认为空;
truncate table TEST_OBJ ;
进行恢复。
记住了,一定要是大写,表名和用户名.
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表数据量很大,恢复时间比较久。
insert into TEST_OBJ select * from SYS.TEST_OBJ$$;
commit;
tmp下有表空间的数据文件,如果用完了的话,建议删除fy_rec_Data,fy_rst_data表空间。
drop tablespace fy_rec_data including contents and datafiles;
drop tablespace fy_rst_data including contents and datafiles;
下次需要恢复的时候建两个表空间就好了。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章