只言片语分析datapump的工作原理

datapump是从oracle 10g推出的新的数据导入导出工具，可以说是exp/imp的加强版，主要的亮点在于服务端,结合了direct+parallel，而且从datapump的结构上来说也和exp/imp有很大的差别。而老式的exp/imp还有一套自己的数据字典表需要维护，习惯了exp/imp，突然切换到expdp/impdp还有是一些抵触情绪的，因为从之前的感触中没有感受到datapump的强大，从公司的team的反馈，产品线中也遇到了不少的bug.但是很多东西你熟悉了了解了，就会明白oracle设计它的一些原因和出发点，有些小的问题也是可以接受的。
datapump官方没有提供很多Internal的东西，都只限于操作层面。以下内容都基于个人理解，欢迎拍砖。

一般来说在数据的导入过程中，oracle会创建3个临时的表，之前在排查Impdp临时中断的问题中注意到了这个细节，但是如何把他们关联一直没有头绪。http://blog.itpub.net/23718752/viewspace-1189257/
IMPORT的表类似下面的形式
SYS_IMPORT_TABLE_28 
ERR的表类似下面的形式。
ERR$DP13FC20810001

ET的表类似下面的形式。
ET$ 1B5C6DCF0001

如果尝试访问这些表ET,ERR，会马上抛出ora错误，可以看出这些临时表是基于external table的形式，而且是不对外访问的，在数据导入完成之后就会自动清空。
SQL> select *from ET$1B5C6DCF0001;
ERROR:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
KUP-11024: This external table can only be accessed from within a Data Pump
job.

而且impdp相对Imp有一个特别的优点就是可以随时查看导入的进度。使用Impdp  xxxx attach= SYS_IMPORT_TABLE_28  的形式就可以查看导入的数据量，导入的进度。这些情况基本都是基于 SYS_IMPORT_TABLE_28 表来读取的信息，它基本就是一个控制表。

而ET,ERR的表是怎么关联的呢，直到有一天我查看一个性能问题的时候，从awr的日志中发现了如下的一段内容,关于datapump的。

Elapsed Time (s)	Executions	Elapsed Time per Exec (s)	%Total	%CPU	%IO	SQL Id	SQL Module	SQL Text
3,553.36	0		1.01	35.03	10.32	6cz7m51m82vqg	Data Pump Worker	INSERT /*+ PARALLEL("MO1_MEMO"...

相关的sql如下：

6cz7m51m82vqg

INSERT /*+ PARALLEL("TEST_MEMO", 1)+*/ INTO RELATIONAL("APPO"."TEST_MEMO" NOT XMLTYPE) ("APP_ID", "ENTITY_KEY", "PERIOD_KEY", "MEMO_ID", "SYS_CREATION_DATE", "SYS_UPDATE_DATE",xxxxxxxx, "ATTR10VALUE", "CLOB_IND", "MEMO_SYSTEM_TEXT_C") SELECT "APP_ID", "ENTITY_KEY", "PERIOD_KEY", "MEMO_ID", "SYS_CREATION_DATE", "SYS_UPDATE_DATE", xxxxxxxx, "ATTR10VALUE", "CLOB_IND", "MEMO_SYSTEM_TEXT_C" FROM "ET$111D05F70001" KU$ LOG ERRORS INTO "APPO"."ERR$DP111D05F70001" REJECT LIMIT UNLIMITED

可以很清楚的发现原来datapump内部在做这样的操作
使用Insert select的方式做数据的插入。几种ET的表是作为中间的数据缓存表，而ERR的表则是完全基于oracle的新版本特性，启用了错误日志。
有了这些信息也就明白，datapump在数据有冲突的情况下是怎么缓存那些信息的。这些信息都被放入了ERR的表中。

 Rejected row #1043:

   column APP_ID: 1000
   column ENTITY_KEY: 1
   column PERIOD_KEY: 2
   column MEMO_ID: 34141901

可能仔细查看上面的sql语句发现insert select可能不是最好的方式，为什么不适用insert /*+append*/ select的方式呢，你可以简单做一个测试就会发现，其实在数据的插入中如果启用错误日志，再启用append模式是冲突的。参见：http://blog.itpub.net/23718752/viewspace-1190545/
上面的例子中我导入数据的表中还有CLOB字段，尽管在Impdp中指定了parallel，但是在实际的插入中还是并行度为1.

所以基于以上信息，可以发现parallel的情况也是根据数据的情况来制定的，append的方式在某些情况下速度可能更快，可以根据自己的需要来选择，甚至手工来完成。
  

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1198655/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1198655/