影响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引擎在执行导出操作时将会等待由其它会话所持有的行锁与表锁先释放再执行导出操作而典型导出工具不会等待。因此导出一张正在被频繁更新的表要比导出一个当前没有被更新的表要慢
12c中禁用日志
在12c中,在Data Pump中引入了新的TRANSFORM的选项DISABLE_ARCHIVE_LOGGING,这对于表和索引在导入期间提供了关闭Redo日志生成的灵活性。当为TRANSFORM选项指定了DISABLE_ARCHIVE_LOGGING:Y值,那么在整个导入期间,表和索引的Redo日志就会处于关闭状态,仅生成少量的日志。这一功能在导入大型表时缓解了压力,并且减少了过度的Redo产生,从而加快了导入。这一属性对表和索引都适用。不管是在非归档还是归档情况下使用DISABLE_ARCHIVE_LOGGING都会减小导入时间,减少归档量。但是需要注意的是,如果数据库处于FORCE LOGGING模式,那么DISABLE_ARCHIVE_LOGGING参数会无效。
以下SQL演示了这一功能:
impdp directory=dpump dumpfile=abcd.dmp TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y logfile=abcd.log
impdp hr/hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp SCHEMAS=hr TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y -- 表和索引都关闭日志
impdp hr/hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp SCHEMAS=hr TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y:TABLE -- 只有表关闭日志
impdp hr/hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp SCHEMAS=hr TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y TRANSFORM=DISABLE_ARCHIVE_LOGGING:N:INDEX
“TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y”表示表和索引都关闭日志。
有关该新特性需要注意以下几点:
① 在导入完成后,表和索引的状态(包括LOGGING状态和索引是否有效的状态)都会恢复到导入之前的状态。
② 在使用该参数导入数据文件后,如果相应的datafile被restored和recovered,那么接下来的涉及到目标表的查询会报ORA-01578和ORA-26040的坏块错误。例如:
例如:
SQL> select * from test_nologging;
ORA-01578: ORACLE data block corrupted (file # 11, block # 84)
ORA-01110: data file 4: '/oradata/users.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
因此,在使用该参数导入数据文件后,需要立马对相关的数据文件做RMAN备份。
11.2.0.4含有大的clob字段
若是11.2.0.4的版本,表含有大的CLOB字段,则做导出操作会非常慢,这是一个bug,可以参考:DataPump Export (EXPDP) Is Taking Long time To Export Tables With BASICFILES (Doc ID 1595380.1)
解决慢的问题请参考:https://www.xmmup.com/oracle-11-2-0-4-expdpdaochuhanclobziduanbasicfiledebiaochaojimandewenti.html
ORA-01555报错解决参考:https://www.xmmup.com/oracleshujubengexpdpdaochubaoora-01555heora-22924.html#ke_neng_yuan_yin_er
总结
1、主要是通过parallel参数来提高数据泵的性能,参考:https://www.xmmup.com/oracleshujubengexpdpheimpdpzhiparallelcanshu.html#zong_jie
expdp \'/ AS SYSDBA\' directory=D1 dumpfile=orcl_%U.dmp EXCLUDE=STATISTICS LOGFILE=expdp_orcl_20221111.log \
SCHEMAS=scott,lhr CLUSTER=N COMPRESSION=ALL parallel=32 FILESIZE=10g
impdp \'/ AS SYSDBA\' directory=D1 dumpfile=orcl_%U.dmp FULL=Y parallel=32 CLUSTER=N table_exists_action=REPLACE
2、若是本地磁盘空间足,后期传输到目标端网络带宽足,那么可以考虑不用压缩参数,去掉COMPRESSION=ALL
来加速导出过程
3、若是12c,可以在导入参数中加入TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y
:
impdp directory=dpump dumpfile=abcd.dmp TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y logfile=abcd.log
4、排除统计信息和不再需要的大表
5、若是11.2.0.4且含有clob字段的大表,则需要重建表修改存储属性STORE AS securefile
,再进行导出才会解决慢的问题。参考:https://www.xmmup.com/oracle-11-2-0-4-expdpdaochuhanclobziduanbasicfiledebiaochaojimandewenti.html
6、在导出导入的过程中,可以通过如下的SQL查询进度
SELECT d.sid,
d.SESSION_SERIAL#,
d.sql_id,
d.SQL_TEXT,
d.MODULE,
D.SQL_EXEC_START,
trunc(d.ELAPSED_TIME / 1000000) ELAPSED_TIME_S
FROM v$sql_monitor d
where d.STATUS = 'EXECUTING'
AND D.MODULE like '%Data Pump%'
order by d.MODULE;
-- 可直接使用
SET LINE 9999 PAGESIZE 9999
col username format a10
col OSUSER format a10
col target format a20
col opname format a30
col WAIT_CLASS format a20
col wait_event format a30
col message format a80
col SQL_TEXT format a100
col sofar_TOTALWORK format a20
col session_info format a15
col progress format a8
SELECT a.USERNAME,
(SELECT upper(nb.OSUSER) FROM v$session nb WHERE nb.SID = a.sid) OSUSER,
(SELECT nb.sid || ',' || nb.SERIAL# || ',' || pr.SPID
FROM v$process pr, v$session nb
WHERE nb.PADDR = pr.ADDR
and nb.sid = a.SID
and nb.SERIAL# = a.SERIAL#) session_info,
a.opname,
to_char(a.START_TIME, 'YYYY-MM-DD HH24:MI:SS') start_time,
round(a.SOFAR * 100 / a.TOTALWORK, 2) || '%' AS progress,
a.TIME_REMAINING TIME_REMAINING,
a.elapsed_seconds elapsed_seconds,
message message,
(SELECT nb.EVENT FROM V$session_Wait nb WHERE nb.SID = a.SID) wait_event,
(SELECT nb.STATUS FROM v$session nb WHERE nb.SID = a.SID) STATUS
FROM v$session_longops a
WHERE a.time_remaining <> 0
ORDER BY status, a.TIME_REMAINING DESC, a.SQL_ID, a.sid;