前言
TRUNCATE不会逐个清除用户数据块上的数据，而仅仅重置数据字典和元数据块上的元数据（如存储段头和扩展段图）。也就是说，此时，其基本数据并未被破坏，而是被系统回收、等待被重新分配。
如果我们已经有一套元数据及数据块，然后将被TRUNCATE的用户数据块的内容取代其用户数据块的内容，是否可以“骗”过Oracle，让它读出这些数据呢？ 回顾一下表扫描的过程，这个方法应该是可行的。我们只要想办法构造出一个结构相同、且具有完整元数据信息和格式化了的用户数据块的傀儡表对象，然后将被TRUNCATE的用户数据块找出，再将其数据内容部分嫁接到傀儡对象的用户数据块，使Oracle以外这是傀儡对象的数据，就能让Oracle扫描并读出数据内容。
1.创建测试表
SQL> create table pak_tab as select * from dba_objects;
Table created.
SQL> select count(*) from pak_tab;
COUNT(*)
———-
86262
2.truncate table pak_tab
SQL> truncate table pak_tab;
Table truncated.
SQL> select count(*) from pak_tab;
COUNT(*)
———-
0
SQL> select owner from sys.pak_tab where rownum<=1;
OWNER
——————————
SYS
3 编译fy_recover_data包
SQL> @fy_recover_data.pck
Package created.
Package body created.
4.执行fy_recover_data包
SQL> exec fy_recover_data.recover_truncated_table(‘sys’,’pak_tab’);
PL/SQL procedure successfully completed.
SQL> SELECT COUNT(*) FROM pak_tab;
COUNT(*)
———-
0
SQL> SELECT COUNT(*) FROM pak_tab$$;
COUNT(*)
———-
86262
5.把数据插回原表
SQL> alter table pak_tab nologging;
Table altered.
SQL> insert /*+append*/ into pak_tab select * from pak_tab$$;
86262 rows created.
SQL> commit;
Commit complete.
SQL> alter table pak_tab logging;
Table altered.
6.校验数据
SQL> select count(*) from pak_tab;
COUNT(*)
———-
86262
总结
1，删除因为恢复表自动创建的两个表空间
- drop tablespace fy_rec_data including contents and datafiles;
- drop tablespace fy_rst_data including contents and datafiles;
2，truncate以后，要保证没有新数据灌入
3，存储该表的数据文件不能覆盖。否则无法完成恢复。
4，紧急时刻可以将表空间设为只读
5，备份的关键性，合理的备份策略是DBA最后的救命稻草，请重视备份！对数据怀有敬畏之心！！
到此这篇关于Oracle使用fy_recover_data恢复truncate删除的数据的文章就介绍到这了,更多相关Oracle 恢复truncate删除数据内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
