共计 4723 个字符，预计需要花费 12 分钟才能阅读完成。
当执行 datapump 导出和导入时都想尽一切办法来提高性能，这里介绍一些可以显著提高 DataPump 性能的相关 DataPump 与数据库参数
一. 影响 DataPump 相关的 DataPump 参数
access_method
在某些情况下由 Data Pump API 所选择的方法不能快速的访问你的数据集。在这种情况下除了显式地设置该参数来测试每一种访问方法之外你是无法知道那种访问方法更高效的。该参数有两种选项 direct_path 与 external_table
cluster=n
在 RAC 环境中可以显著提供高 Data Pump API 基本操作的速度。注意这个参数只对 Data Pump API 操作起作用，在 RAC 环境中，建议将该参数设置为 n。而如果将 parallel_force_local 设置为 true 所带来的影响不仅仅只针对 Data Pump API 操作
data_options=disable_append_hint
它只是 impdp 参数，在非常特殊的情况下，可以安全的使用并且可能减少导入数据的时间。只有满足以下所有条件时才使用 data_options=disable_append_hint 参数。
1. 导入操作将向已经存在的表，分区或子分区导入数据
2. 将被导入的已经存在的对象数非常少(比如是 10 或者更小)
3. 当执行导入操作时其它会话对于这些被导入的对象只执行 select 语句。
data_options=disable_append_hint 参数只有在 11.2.0.1 与更高版本中才可以使用。只有在要锁定由其它会话所释放对象花费很长时间的情况下使用 data_option=disable_append_hint 才能节省时间。
estimate
estimate 参数有两个相互排斥的选项，一个是 blocks，另一个是 statistics. 在执行导出操作时使用 blocks 方法来评估数据集大小比使用 statistics 方法消耗的时间更长。但是使用 blocks 方法评估的数据集大小要比使用 statistics 方法评估的数据集大小要精确些。如果导出文件的评估大小不是最主要关注的事，建议使用 estimate=statistics。
exclude=comment
在某些情况下，终端用户不需要列和对象类型对应的注释，如果忽略这些数据，DataPump 操作将会减少执行时间。
exclude=statistics
如果不需要使用排斥的 include 参数，那么排除和导出统计信息将会缩短整个导出操作的时间。dbms_stats.gather_database_stats 过程将在数据导入到目标数据库后来生成统计信息。DataPump 操作当由 DataPump 引擎和任何其它的 RDBMS 会话并行执行对小表生成统计信息时可能会 hang 且无限期。对于运行时间超过 1 小时或更长时间的 DataPump 操作，可以考虑禁用数据库的自动统计信息收集任务为了临时禁用 11g 的自动统计信息收集任务因此 DataPump 操作不会与该任务产生竞争，以 sys 用户执行以下命令:
exec dbms_auto_task_admin.diable(client_name=>’auto optimizer stats collection’,
operation=>null,window_name=>null);
在 DataPump 操作完成之后重新启动统计信息收集任务:
exec DBMS_AUTO_TASK_ADMIN.ENABLE(client_name => ‘auto optimizer stats collection’, operation => NULL, window_name => NULL);
为了临时禁用 10g 的自动统计信息收集任务因此 DataPump 操作不会与该任务产生竞争，以 sys 用户执行以下命令:
exec sys.dbms_scheduler.disable (‘GATHER_STATS_JOB’);
在 DataPump 操作完成之后重新启动统计信息收集任务:
exec sys.dbms_scheduler.enable (‘GATHER_STATS_JOB’);
network_link
使用这个参数将会有效限制 DataPump API 的并行度，除非你的网络吞吐量和网络带宽比本地设备更好，使用 network_link 将会比使用导出文件慢很多。对于 DataPump API 性能来说，因为它倾向于比 dump 文件操作要慢很多，只建议 network_link 作为最后一招来使用。可以考虑使用移动或共享设备来存储 dump 文件来代替 network_link 来执行数据的迁移。
parallel
如果有多个 CPU 使用并且没有使用 CPU 绑定或磁盘 I / O 绑定或内存绑定且在 dumpfile 参数中没有使用多个 dump 文件，那么并行执行将会对性能产生正面影响。如果 parallel 参数设置为 N,N>1，那么为了更好的使用并行执行建议 dumpfile 参数应该设置为不比 parallel 参数小。
需要注意的是，parallel 参数是 DataPump API 可以使用的并发 Data Pump 工作进程的上限，但 DataPump API 可能使用的 DataPump 工作进程数要比这个参数指定的少，依赖于主机环境中的瓶颈，parallel 参数指定的值小于可用 CPU 个数时 Data Pump API 基本操作可能会更快。
query
使用 query 参数会显著增加任何 DataPump API 基本操作的负载，这种开销与被查询表的数据量成正比。
remap_*
使用任何 remap_* 参数会显著增加任何 DataPump API 基本操作的负载，这种开销与被查询表的数据量成正比。
二. 影响 DataPump 操作性能的相关数据库参数
aq_tm_processes=0
当这个参数被显式设置为 0，可能对高级队列操作产生负面影响，进而对使用高级队列的 DataPump 基本操作产生负面影响。可以复原这个参数或者设置一个大于 0 的值
deferred_segment_creation=true
只适用于导入操作，这将会消除为空表分配空间所花费的时间。对于导出操作设置这个参数将不会对性能产生显著的影响。这个参数在 11.2.0.2 或更高版本中非常有用。
filesystemio_option=…
在特定情况下数据库实例将会对 ACFS 文件系统执行写操作，指定 Data Pump API 执行的写操作类型性质作为导出操作的一部分，NONE 以外的其它参数值都可能造成导出操作变慢。
NLS_CHARACTERSET=… and NLS_NCHAR_CHARACTERSET=…
当源数据库与目标数据库之间这两个参数存在差异时，在任何时候执行导入操作时对于指定的分区表都不能使用多个 DataPump 工作进程来创建分区表和填充。在有些情况下，只有一个 DataPump 工作进程可以对表数据执行操作，这将会对表获得排他锁来阻止任何其它 DataPump 工作进程对相同的表执行操作。当分区表不存在排他锁时可以使用多个 DataPump 工作进程同时操作来显著提高对分区表导入数据的性能。
NLS_COMP=… and NLS_SORT=…
在一些罕见的情况下，数据库的这两个参数被设置为了 binary 这将显著提高 DataPump API 基本操作的速度。对于你的环境是否将这两个参数设置为 binary 能提高性能需要进行测试。在会话登录后在会话级别设置这两个参数可以通过以下的登录触发器来实现。
CREATE OR REPLACE TRIGGER sys.expdp_nls_session_settings AFTER LOGON ON DATABASE
DECLARE
V_MODULE VARCHAR2(60);
BEGIN
SELECT SYS_CONTEXT (‘USERENV’, ‘MODULE’) INTO V_MODULE FROM DUAL;
IF UPPER(V_MODULE) LIKE ‘UDE%’
THEN
BEGIN
EXECUTE IMMEDIATE ‘ALTER SESSION SET NLS_COMP=”BINARY”’;
EXECUTE IMMEDIATE ‘ALTER SESSION SET NLS_SORT=”BINARY”’;
END;
END IF;
END;
/
parallel_force_local=true
在 RAC 环境中可以显著提高 DataPump API 基本操作的性能并且避免并行 DML 操作的 bug。但这个参数只能对 11.2.0.2 或更高版本使用。
streams_pool_size
为了避免 bug 17365043 ‘STREAMS AQ: ENQUEUE BLOCKED ON LOW MEMORY WHEN REDUCING STREAMS_POOL_SIZE’
建议将 streams_pool_size 设置以下查询所返回的结果值
select ‘ALTER SYSTEM SET STREAMS_POOL_SIZE=’||(max(to_number(trim(c.ksppstvl)))+67108864)||’ SCOPE=SPFILE;’
from sys.x$ksppi a, sys.x$ksppcv b, sys.x$ksppsv c
where a.indx = b.indx and a.indx = c.indx and lower(a.ksppinm) in (‘__streams_pool_size’,’streams_pool_size’);
_memory_broker_stat_interval=999
如果在你的缓慢 DataPump 环境中 resize 操作消耗了大量时间，那么设置这个参数将会减少 resize 操作的频率，进而在一个指定时间跨度内减少 resize 操作延迟其它操作的所花的时间。这是因为 DataPump API 依赖大量的流功能来帮助导出和导入操作。建议将这个参数设置为 999，如果 streams_pool_size 参数已经被显式设置并且频繁的出现 resize 操作。
三. 表 DDL 级别影响 DataPump 性能的相关参数
network_link+securefiles
network_link 参数当移动包含有 lob 列的表，且 lob 是为了使用 securefiles 将会使移动操作非常缓慢，当使用 network_link 参数移动包含用了使用 securefiles 而有 lob 列的表时会生成大量 undo 数据。原因是分布式事务分配请求被限制为跨数据库链路一次只有一个数据块，这意味着大数据集传输将会产生更多的传输。
securefiles(不使用 network_link)
使用 securefiles 存储格式来存储 LOB 列数据允许包含 lob 列的表使用并行执行导出和导入
使用 basicfiles 存储格式来存储 LOB 列数据不允许包含 lob 列的表使用并行执行导出和导入
四. 表 DML 级别影响 DataPump 性能的相关参数
在 DataPump 操作和另一个访问数据库对象的会话之间产生竞争（通常是对表，行数据的锁）
DataPump 引擎在执行导出操作时将会等待由其它会话将其持有的行锁与表锁先释放，再执行相关表的导出和导入。DataPump 引擎在执行导出操作时将会等待由其它会话所持有的行锁与表锁先释放再执行导出操作而典型导出工具不会等待。因此导出一张正在被频繁更新的表要比导出一个当前没有被更新的表要慢
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-04/130339.htm
