首页 » ORACLE 9i-23c » Troubleshooting Oracle 12cR1 Expdp is slow Bugs

Troubleshooting Oracle 12cR1 Expdp is slow Bugs

最近一个交通行业的客户近400TB的数据库,需要导出100T的历史数据后清理,但使用Datapump Expdp导出过程遇到了好几个问题且是已知bug ,简单记录. 首先注意如果使用NFS作为expdp的directory, 确认的使用正确的mount option,  同时如果远程是一些其它文件系统如ZFS或Vxfs ,要注意日志和碎片带来的性能影响,建议先在本地文件系统测试导出正常。

1,expdp 导出后hang在估算大小阶段
expdp任务的最开始,然后近多个小时没有返回,数据库确实大,有180W个对象。

$ expdp scott/tiger@pdb1 tables=emp directory=test_dir dumpfile=emp.dmp logfile=expdp_emp.log logtime=all

Export: Release 12.1.0.1.0 - Production on Wed Apr 20 22:11:57 2023

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics
and Real Application Testing options
20-Apr-23 22:12:09.312: Starting "SCOTT"."SYS_EXPORT_TABLE_01":  scott/********@pdb1 tables=emp directory=test_dir dumpfile=emp.dmp logfile=expdp_emp.log logtime=all 
-- hang
---

查看expdp的session

select * from DBA_DATAPUMP_JOBS;

select to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') "DATE", s.program, s.sid,
s.status, s.username, d.job_name, p.spid, s.serial#, p.pid,
s.event,s.status,s.sql_id
from v$session s, v$process p, dba_datapump_sessions d
where p.addr=s.paddr and s.saddr=d.saddr;

Note:
当然也可以在expdp时增加trace=480300启用trace跟踪,查看SID_dm, SID_dw的trace文件,我们也可以通过查看当时的session状态,因为expdp是会生成后面调度去导出,并不是OS层 expdp一个进程的连接, 如v$session中可以看到datapump session进程如ude@xxx, DMnn, DWnn. 这个hang的session 我们能看到大部分是等 single block physical read event, 并且在执行下面的递归SQL

SELECT SUM(:B4 *E.KTFBUEBLKS)
FROM
SYS.X$KTFBUE E WHERE E.KTFBUESEGTSN = :B3 AND E.KTFBUESEGFNO = :B2 AND
 E.KTFBUESEGBNO = :B1

使用默认的 ESTIMATE=BLOCKS 时,DataPump Export (EXPDP) 非常慢,并且在导出数千个表时在 ESTIMATE 阶段花费了几个小时。 从DataPump Export的sql trace文件来看,几乎所有的时间都花在了上面的递归SQL上。默认 ESTIMATE=BLOCK 时,DataPump Export (expdp) 基本上会扫描字典以识别每个段大小,以便计算估计的空间需求。 DataPump 在每个段上运行此查询。因此,如果导出的段数量太大,则需要花费时间来扫描所有段。 开发部门已通过 Bug 17898577 将这种执行缓慢的情况归类为“不是错误” – EXPDP SLOW WHEN USING ESTIMATE=BLOCKS DUE TO HIGH EXECUTIONS OF SYS.X$KTFBUE。

解决方法
导出时增加ESTIMATE=STATISTICS

2, expdp导出hang在processing /STATISTICS/MARKER:
当表导完后,最后的阶段会停留在这里,即使增加了exclud=statistics.  在sql trace或查看DW00 session在执行下面的SQL

insert into "SYS"."IMPDP_STATS" select null, type, version, flags,c1, c2, c3, c4, c5, c6, n1, n2, n3, n4, n5, n6, n7, n8, n9, n10, n11, n12, n13, d1, t1, r1, r2, r3, ch1, cl1 from sys."_user_stat" st
where type in ('T','C','E','P','M','U','G','L') and (type not in ('t','c','i') or :1 is null or :2 < t1) and c5 = :3 and c1 = :4

在某些情况下,由于优化器计划错误,插入表 impdp_stats 的速度很慢。 由于bootstrap indexes的统计负载问题,选择了较差的执行计划。开发部门已在 Bug 21644640 – 12C (12.1.0.2) EXPDP HANGS ON INSERT INTO TABLE IMPDP_STATS 中调查了此优化器问题,已在 12.2 中修复。

解决创建1个索引

# Create the following index:
create index SYS.IMPDP_STATS_1 ON SYS.IMPDP_STATS (c5,type,c1,c2,c3,c4,statid,version);
and re-run the DataPump job

3, ORA-27086: unable to lock file – already in use
在本机已可以分钟级导出,改为导出到NFS后提示下面的错误

ORA-01580: error creating control backup file xxx
ORA-27086: unable to lock file - already in use
HPUX-ia64 Error: 22: Invalid argument
Additional information: 9
Additional information: 22

之前在测试NFS上安装RAC也曾遇到过类似问题《荆棘载途 RAC安装之NFS篇》

解决方法
1, 启动nfslock 服务

# service nfslock start

2, NFS mount option增加nolock

rw,noac,hard,rsize=32768,wsize=32768,nolock

— over —

打赏

,

对不起,这篇文章暂时关闭评论。