使用impdp不当导致的数据丢失问题(r5笔记第1天)

今天有个朋友问我们一个问题，说他在使用了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