前言

TRUNCATE不會逐個清除用戶數(shù)據(jù)塊上的數(shù)據(jù)，而僅僅重置數(shù)據(jù)字典和元數(shù)據(jù)塊上的元數(shù)據(jù)（如存儲段頭和擴(kuò)展段圖）。也就是說，此時，其基本數(shù)據(jù)并未被破壞，而是被系統(tǒng)回收、等待被重新分配。

如果我們已經(jīng)有一套元數(shù)據(jù)及數(shù)據(jù)塊，然后將被TRUNCATE的用戶數(shù)據(jù)塊的內(nèi)容取代其用戶數(shù)據(jù)塊的內(nèi)容，是否可以“騙”過Oracle，讓它讀出這些數(shù)據(jù)呢？ 回顧一下表掃描的過程，這個方法應(yīng)該是可行的。我們只要想辦法構(gòu)造出一個結(jié)構(gòu)相同、且具有完整元數(shù)據(jù)信息和格式化了的用戶數(shù)據(jù)塊的傀儡表對象，然后將被TRUNCATE的用戶數(shù)據(jù)塊找出，再將其數(shù)據(jù)內(nèi)容部分嫁接到傀儡對象的用戶數(shù)據(jù)塊，使Oracle以外這是傀儡對象的數(shù)據(jù)，就能讓Oracle掃描并讀出數(shù)據(jù)內(nèi)容。

1.創(chuàng)建測試表

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.執(zhí)行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.把數(shù)據(jù)插回原表

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.校驗數(shù)據(jù)

SQL> select count(*) from pak_tab;

COUNT(*)
----------
86262

總結(jié)

1，刪除因為恢復(fù)表自動創(chuàng)建的兩個表空間

• drop tablespace fy_rec_data including contents and datafiles;
• drop tablespace fy_rst_data including contents and datafiles;

2，truncate以后，要保證沒有新數(shù)據(jù)灌入

3，存儲該表的數(shù)據(jù)文件不能覆蓋。否則無法完成恢復(fù)。

4，緊急時刻可以將表空間設(shè)為只讀

5，備份的關(guān)鍵性，合理的備份策略是DBA最后的救命稻草，請重視備份！對數(shù)據(jù)懷有敬畏之心??！