10g以来，我们有什么理由不选择 数据泵 呢？

注：本文属个人总结，仅针对自己觉得有必要总结的环节，而非tips，具体操作细节可参考联机文档 或 -help

 

一.凡事都有起因，让我们不得不面对问题进行思考：

win2003 10.2.0.1  client 导出 centos5.7 11.2.0.3 server    出现 错误

EXP-00008: 遇到 ORACLE 错误 1455
ORA-01455: 转换列溢出整数数据类型
EXP-00000: 导出终止失败

简单查了一下，应该是统计信息导致（未深入考证）

exp中使用了 statistics=none 无效；

在测试环境将server端删除统计信息后再试，仍然无效。 暂没有可靠的办法时，想到了expdp。   过去我一直不愿使用expdp，这种固步自封的态度要不得。

然后对数据泵的特性稍作整理 并加以 测试，果然柳暗花明又一村！

 

二. expdp/impdp相对于exp/imp  的改进

1.不依赖网络：即不再依赖服务名，expdp的操作全部在server端执行。

2.可配置并行：下面会简单测试到

3.任务可重启：既然抛弃了客户端，这一特性是必须的！

4.不需要赋予系统权限，仅需要赋予对象权限，即：directory的读写权限   eg:  sys@contos1> grant  read,write  on directory dp to pjh;

 

三.导出时间对比  (2g dump)

exp   direct=y      6分钟

expdp 默认         3分钟

expdp 并行10    5分钟

如果在不增加导出文件数量的前提下增加并行数，基本没有效果 

 

 

四.expdp/impdp 可以有优异的压缩比

1. 10g数据泵诞生，就引入了compression功能

2.11g 比10g  的compression 增加了all 与 data_only 选项

 

 

五. 轻易消除跨版本迁移数据的尴尬,这是我不能拒绝数据泵的一个最重要的理由！

1.在exp/imp时代，我们需要参考兼容性矩阵，无比麻烦。

2. 当我们使用高版本expdp后，在低版本impdp时，可能会遇到，ora-39142: 版本号3.1(......)不兼容。

    只要我们在高版本expdp时，指定version=10.2.0.1 就可以轻易解决。但是注意新版本的特性将不可使用，例如compression=all.

 

六. 常用的参数 

 更换schema      remap_schema=“schema_A:schema_B”

还有很多的remap ，很强大，参见 -help

 

七. 平时使用时，形成规范

 1. 我们每次执行expdp/impdp是，都应该手动指定job_name，并且关注MT的状态. 这样我们在attach时，会比较快捷

 2. 在服务器常备几个重要的 expdp 或者 impdp脚本

 3. 我们应该在需要使用数据泵的server上提前规划好directory所属目录，从独立性、易管理、空间充足为重点考虑

 

八.我们应该善于接受新的方法,新的特性。凡是存在均有其合理性！

exp/imp已经成为过去，如果不是9i，建议使用数据泵！  

 

九. 简单的例子

expdp pjh/123 dumpfile=dzsw1.dp directory=dp version=10.2.0.1 job_name=jzt1 PARALLEL=1

impdp pjh/123 dumpfile=V3PRO.DP directory=dp schemas="A" remap_schema="A:B" job_name=jzt1