Oracle使用fy_recover_data恢复truncate删除的数据

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

1. SQL> truncate table pak_tab; 
2. Table truncated. 
3. SQL> select count(*) from pak_tab; 
4. COUNT(*) 
5. ---------- 
6. 0 
7. SQL> select owner from sys.pak_tab where rownum<=1; 
8. OWNER 
9. ------------------------------ 
10. SYS 

3 编译fy_recover_data包

1. SQL> @fy_recover_data.pck 
2. Package created. 
3. Package body created. 

4.执行fy_recover_data包

1. SQL> exec fy_recover_data.recover_truncated_table('sys','pak_tab'); 
2. PL/SQL procedure successfully completed. 
3. SQL> SELECT COUNT(*) FROM pak_tab; 
4. COUNT(*) 
5. ---------- 
6. 0 
7. SQL> SELECT COUNT(*) FROM pak_tab$$; 
8.  
9. COUNT(*) 
10. ---------- 
11. 86262 

5.把数据插回原表

1. SQL> alter table pak_tab nologging; 
2. Table altered. 
3. SQL> insert /*+append*/ into pak_tab select * from pak_tab$$; 
4. 86262 rows created. 
5. SQL> commit; 
6. Commit complete. 
7. SQL> alter table pak_tab logging; 
8. Table altered. 

6.校验数据

1. SQL> select count(*) from pak_tab; 
2.  
3. COUNT(*) 
4. ---------- 
5. 86262 

总结

1，删除因为恢复表自动创建的两个表空间

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最后的救命稻草，请重视备份！对数据怀有敬畏之心！！