今天有個朋友問我們一個問題，說他在使用了impdp匯入資料的時候，使用了TABLE_EXISTS_ACTION=REPLACE這個選項，結果現在資料都給覆蓋了。現在沒有備份，想問問能不能做相應的恢復操作。 對於這個選項，自己看著熟悉，不過很少用到，碰到了這個問題，首先想到的就是閃回。 不過也不能敷衍，自己在本地做了一個測試，想看看閃回的效果怎麼樣。首先簡單模擬了一下這個問題。 conn n1/n1 SQL> create directory oradmp as '/home/ora11g/oradmp'; --建立目錄 SQL> grant read,write on directory oradmp to test; --賦予目錄許可權 SQL>create table test as select *from cat; --建立一個表test

然後嘗試匯出 [ora11g@oel1 oradmp]$ expdp n1/n1 dumpfile=a.dmp directory=oradmp tables=test Export: Release 11.2.0.1.0 - Production on Thu Apr 9 14:13:33 2015 。。。 Starting "N1"."SYS_EXPORT_TABLE_01": n1/******** dumpfile=a.dmp directory=oradmp tables=test . . exported "N1"."TEST" 5.476 KB 4 rows Master table "N1"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded ****************************************************************************** 然後在測試使用者中也建立一個表test,只有一條資料。 SQL> create table test as select *from cat; SQL> select count(*)from test; COUNT(*) ---------- 1 然後嘗試匯入，啟用TABLE_EXISTS_ACTION的選項 [ora11g@oel1 oradmp]$ impdp test/test dumpfile=a.dmp TABLE_EXISTS_ACTION=replace directory=oradmp With the Partitioning, OLAP, Data Mining and Real Application Testing options ORA-31655: no data or metadata objects selected for job ORA-39154: Objects from foreign schemas have been removed from import Master table "TEST"."SYS_IMPORT_FULL_01" successfully loaded/unloaded Starting "TEST"."SYS_IMPORT_FULL_01": test/******** dumpfile=a.dmp TABLE_EXISTS_ACTION=replace directory=oradmp Job "TEST" 發現報了ORA錯誤，初步以為可能是11.2.0.1.0 的bug導致的，在公司64位的環境上模擬了一下，還是能夠復現。在MOS上查了下，文章Doc ID 1341446.1給出瞭解決方法，就是新增remap_schema即可。 再次匯入就沒有問題了。 impdp test/test dumpfile=a.dmp directory=oradmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Master table "TEST"."SYS_IMPORT_FULL_01" successfully loaded/unloaded Starting "TEST"."SYS_IMPORT_FULL_01": test/******** dumpfile=a.dmp directory=oradmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/TABLE_DATA . . imported "TEST"."TEST" 5.476 KB 4 rows Job "TEST"."SYS_IMPORT_FULL_01" successfully completed at 15:42:42 這個時候先來看看回收站裡的是否有原來的表，結果show recycle沒有查到任何東西。因為不確定replace的實際範圍，可能有truncate+insert,delete+insert,drop+create,自己使用閃回查看了一下。 select versions_starttime v_starttime,versions_startscn v_startscn,versions_xid xid,versions_endtime vendtime,versions_endscn vendscn,versions_operation oper,table_name from test versions between scn minvalue and maxvalue; 裡面有4條記錄，都是匯入之後的資料，匯入之前的資料就丟失了。 至於show recyclebin中為什麼沒有drop後的表，自己又嘗試新建一個表，做drop操作就沒有問題。 SQL> show recycle ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME ---------------- ------------------------------ ------------ ------------------- TEST1 BIN$E0Tq5KcMjSTgUKjAghtd2w==$0 TABLE 2015-04-09:14:40:03 所以這個時候就有些疑惑，檢視官方文件，文件中提到這個replace是一個drop+create的操作,如果這個時候回收站中還是沒有drop之前的表，只能說明是使用drop table test purge這樣的形式了。 但這個僅僅是猜想，怎麼驗證呢，可以開trace。 impdp本身有個trace選項，但是這個選項在--help中沒有提到。 自己試了下，能夠生成部分的trace，但是和自己的預期還是有差距。 我使用的trace如下。 impdp test/test dumpfile=a.dmp directory=test_dmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test trace=4a0300 開啟trace的時候很可能報出下面的錯誤,只要賦予imp_full_database的許可權即可，可以在匯入之後回收許可權。 [ora11g@oel1 oradmp]$ impdp test/test dumpfile=a.dmp directory=test_dmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test trace=4a0300 Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options ORA-31631: privileges are required SQL> grant imp_full_database to test; Grant succeeded. 日誌生成了,得到的是一些呼叫dbms_datapump的語句，沒有找到drop相關的操作。

嘗試了10046，也貌似沒有生效。 最後來試試logon trigger吧，通過這個來設定10046得到的資訊還是很全的。

CREATE OR REPLACE TRIGGER set_trace_on_logon AFTER LOGON ON DATABASE BEGIN if ( user not in ('SYS','SYSTEM' )) then EXECUTE IMMEDIATE 'alter session set statistics_level=ALL'; EXECUTE IMMEDIATE 'alter session set max_dump_file_size=UNLIMITED'; EXECUTE IMMEDIATE 'alter session set tracefile_identifier='''||user||'_10046'''; EXECUTE IMMEDIATE 'alter session set events ''10046 trace name context forever, level 12'''; end if; END set_10046_trace_on_logon; / 直接通過grep來看看效果。發現執行的是一個drop cascade constraints purge選項。 [ora11g@oel1 trace]$ grep PURGE * TEST11G_dm00_31816_TEST_10046.trc:DROP TABLE "TEST"."SYS_IMPORT_FULL_01" PURGE TEST11G_dw00_31818_TEST_10046.trc:DROP TABLE "TEST"."TEST" CASCADE CONSTRAINTS PURGE TEST11G_j001_12582.trc:*** ACTION NAME:(PURGE_LOG) 2015-04-08 18:00:00.378 所以能夠證明這個purge選項直接徹底清空了表和資料。 這樣的話，只能使用一些非常規手段來 恢復資料了，這個時候可以考慮使用DUL這個工具了。國內也有幾個牛人有自己的工具，ODU來嘗試了。 ODU的使用還是需要花些功夫的。可以參考下面的連結來試試。 http://www.laoxiong.net/category/odu