Oracle12c的datapump功能跟以前差不多，在多租户的环境中执行导入\导出以及使用一些更细化的参数的时候，几乎没有区别，依然很好用，效率很高。目前有很多的用户仍然在使用exp/imp工具在执行一些迁移、备份、过滤和转移数据的工作，相比起来，数据泵的效率更高、更易用并且更方便管理，但exp/imp在有些时候可以完成datapump不适用的情况。两者的操作风格和格式很相似，相信在您掌握了其中任一种工具之后，另一种会很容易上手。

数据泵可以高效备份、复制、保护和传输大量的数据和源数据。在导入和导出过程中可以做到过滤数据和对象，并且能够在全数据库级、方案级、表级和表空间级实现导入导出。

在此，我们简单体验一下数据泵在可插拔数据库中的基本操作过程，你将会发现，跟以前传统的非插拔数据库几乎没有太大区别。 

在Oracle12c的可插拔数据库环境中，首先启动CDB：

[oracle@cafe ~]$ export ORACLE_SID=cup  -----CDB的名字自定义为cup，顾名思义cup作为容器储存数据库，我们的PDB自定义为tea。

 

 

做数据泵的导出需要首先创建目录对象，主要用于作为导出目的地存放导出文件用，应该事检查操作系统中有充足的空间可用并且该空间在数据库服务器本地。这样做的好处之一是可以对目录结构等信息达到保密的安全效果，不赞成使用默认的路径，因为可能会导致空间不足问题，以至于影响数据库正常功能。

在数据库系统中创建相关目录：

 

 

插入测试数据，以备验证后期验证导出、导入的效果：

 

接下来我们执行一次全库导出： 

 

expdp eric/gao directory=dump_dir dumpfile=fullbak.dmp  logfile=fullbak.log full=y

参数解释：

 

• directory：指定的是咱们刚创建的目录对象中的路径别名，在dba_directories中对应着directory_name字段。
• dumpfile：自定义导出文件的filename。
• logfile：可以把整个导入、导出过程中的操作信息输出到文件中，以便后期验证备份效果和排错用。
• full：等于y的时候为全库导出模式。

 

注意：导出所用的用户不要用sys，一般用具有dba角色的用户即可，system也可用。

导出过程：

[oracle@cafe ~]$ expdp eric/gao@tea directory=dump_dir dumpfile=fullbak.dmp   logfile=fullbak.log full=y 
Export: Release 12.1.0.2.0 - Production on Fri Jan 23 18:34:12 2015    -----此行包含版本、导出操作开始的时间，该时间可用于计算导出总时间和记录操作时间点。

 

"ERIC"."SYS_EXPORT_FULL_01"为当前执行的job的名字，可用于中途介入导入、导出过程中调整策略和查看状态。 

 

 

估算本次导入、导出的总大小。 

 

 

此行包含job名称，完成时间和总共使用时间，有时可能没有elapsed，可以根据该操作刚开始的时间做减法，算总时间。 

 

查看一下导出的文件： 

[root@cafe oradump]# ls -lh            

总用量 2.8M

-rw-r----- 1 oracle oinstall 2.8M 1月  23 18:49 fullbak.dmp 

导出的实际容量和其估算的容量还是有一定出入的，因此建议在准备存储空间的时候多预留一些。

-rw-r--r-- 1 oracle oinstall 9.4K 1月  23 18:49 fullbak.log

我们也可以只估算导出文件的大小而不进行实际的导出操作： 

expdp eric/gao@tea  estimate_only=y directory=dump_dir  logfile=n full=y

此处我们使用了estimate_only参数，将该参数置于y状态即可开启估算功能，此处不需要写dumpfile参数，否则可能会报错。 

输出结果：

 

 

此处我们看到，该值跟咱们上一次做实际全库导出过程中算的值一样。 

Job "ERIC"."SYS_EXPORT_FULL_01" successfully completed at Fri Jan 23 22:10:18 2015 elapsed 0 00:01:32

数据泵有一个好处，那就是交互操作模式，我们可以在作业运行中去监控运行状态，并且可以暂停、启动作业，也可以终止作业。

查看正在执行的导入导出状态：

 

 

返回导入/导出命令行输出状态： 

 

暂停正在运行的导入/导出操作，该操作不会导致作业停止，只是暂时停止，类似于断点续传：

 

 

 

附加正在运行的作业，在这里就用到了咱们一再提到的job名称了，使用attach参数指定作业名称就可附加到正在执行或者是暂停的作业中去： 

 

 

启动暂停的作业： 

 

再次查看一下作业的状态有没有发生变化： 

 

 

 

终止数据泵作业，在作业执行中途遇到问题不得不停止的时候，可以用kill_job命令终止操作：

 

 

终止之后系统中不会有实际的导出文件生成： 

[oracle@cafe oradump]$ ls -lt

总用量 4       -rw-r--r-- 1 oracle oinstall 1398 1月  23 22:31 fullbak.log

查看数据泵输出的日志，我们看一下终止操作在日志中的信息： 

 

 

我们删除数据库tea中的表，然后在数据库全备的文件中恢复该表，以验证导出的效果：

 

 

然后从全备份中单独导入test表，在这里我们用全备的备份集，使用table参数保证单独导入该表，保证减小系统开销：

 

 

验证表test已经恢复到了删除之前的状态：

 

 

OK，数据已回来。在实际项目中，可能数据量、环境和客户要求都比此次试验规模庞大、情况复杂，但是万变不离其宗，切记一定实现规划好备份空间，密切的关注备份状态。

 

转：http://www.csdn.net/article/2015-02-02/2823788