Oracle 12.1.0.2 expdp导出分区表数据遇到BUG慢的原因和解决方法

来源：这里教程网时间：2026-03-03 16:15:40 作者：

Oracle expdp导出分区表数据慢的原因和解决方法 简述：Oracle版本12.1.0.2在expdp时导出分区表数据慢，遇到Bug 20236523 : DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY。解决方法：第1种：升级至12.2.0.1；第2种：exp代替expdp。本文我们主要讲第2种方法：exp代替expdp。环境 os：redhat 7.3 db：12.1.0.2 1.原理通透 1.1 原理1 DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY慢的原因： Oracle在有很多分区的对象中错误的使用了TABLE ACCESS BY INDEX ROWID Rows (1st) Row Source Operation ---------- --------------------------------------------------- 1 FILT 1 TABLE ACCESS BY INDEX ROWID EXPDP_FCT_FR_FUND_ACTUAL_TXN (cr=4487 me=286592 us) e=103328 us )(object id 4703807) The tkprof show that the new index is used, but that it is not selective enough for objects with many partitions. bde bug screening complete. #Bug 20236523 - Datapump export is slow using CONTENT=metadata_only(Doc ID 20236523.8) 1.2 原理2 exp direct=y 优化原理：使用直接路径导出，数据直接从磁盘读取到导出session的PGA中，从而跳过了SQL命令处理层 #Parameter DIRECT: Conventional Path Export Versus Direct Path Export (Doc ID 155477.1) 2.解决办法两种 2.1 升级版本 #效果 db：12.1.0.2 expdp 04:26:22 db：12.2.0.1 expdp 01:37:16 2.2 同版本，exp代替expdp #效果 expdp 04:26:22 exp 00:12:00 实现方法 expdp 04:26:22 expdp \'sys/bhlbmc32 AS SYSDBA\' directory=dump dumpfile=expdp_bhl_schemas_${date}_%U.dmp schemas=BMCDB1,BMCDB2 METRICS=Y TRACE=480300 parallel=12 cluster=no logfile=expdp_bhl_schemas_${date}.log exp 00:12:00 exp userid=\"sys/bhlbmc32@bmcCO1 as sysdba\" owner=BMCDB1,BMCDB2 direct=y recordlength=65535 buffer=1048576000 file=/oracle/app/oracle/dump/BMCDB1.20200411.dmp log=/oracle/app/oracle/dump/BMCDB1.20200411.log ##想明白为什么，可以继续读 3.场景重新 3.1 原因分析：expdp为什么那么慢呢？ expdp \'sys/bhlbmc32 AS SYSDBA\' directory=dump dumpfile=expdp_bhl_schemas_${date}_%U.dmp schemas=BMCDB1,BMCDB2 METRICS=Y TRACE=480300 parallel=12 cluster=no logfile=expdp_bhl_schemas_${date}.log #expdp使用METRICS=Y参数查看每个object使用的时间，少于600秒也就是10分钟的省略。大家可以看到涉及table一些统计是很慢的，这是一个值得研究的问题。 Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT Completed 365130 OBJECT_GRANT objects in 7705 seconds Processing object type SCHEMA_EXPORT/TABLE/COMMENT Completed 35606 COMMENT objects in 1098 seconds Processing object type SCHEMA_EXPORT/PACKAGE/GRANT/OWNER_GRANT/OBJECT_GRANT Completed 25413 OBJECT_GRANT objects in 593 seconds Processing object type SCHEMA_EXPORT/FUNCTION/GRANT/OWNER_GRANT/OBJECT_GRANT Completed 100435 OBJECT_GRANT objects in 2923 seconds 3.2 论据：官方MOS参考通过mos查询我们得知其中Bug 20236523 : DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY和我们的问题很相近 Bug 20236523 : DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY MOS描述这个是一个错误的分区扫描引起的。 Rows (1st) Row Source Operation ---------- --------------------------------------------------- 1 FILT 1 TABLE ACCESS BY INDEX ROWID EXPDP_FCT_FR_FUND_ACTUAL_TXN (cr=4487 me=286592 us) e=103328 us )(object id 4703807) The tkprof show that the new index is used, but that it is not selective enough for objects with many partitions. bde bug screening complete. #可想而知一个大型分区表如果没有选择性，直接走TABLE ACCESS BY INDEX ROWID是很可怕的。分区本应该有选择性的走分区，可现在确TABLE ACCESS BY INDEX ROWID（已索引单块读的方式，通过rowid去查询所需的数据），当数据量越大性能消耗越大。 3.3 论点：exp代替expdp绕过这个BUG。我们知道了BUG的原理，生产业务不能立刻升级。我们只能用我们手中的工具来绕过这个BUG。怎么优化这个问题呢？expdp又不能hint执行计划。其实全表扫描也是比TABLE ACCESS BY INDEX ROWID快的。进而想到了exp direct=y，这个不走SQL命令处理的方式。 #Direct path Export，直接导出模式，数据直接从磁盘读取到导出session的PGA中，从而跳过了SQL命令处理层 3.4 论证：生产库中确实有很多分区，符合MOS中BUG的描述。反推如果数据库中真的有很多分区，所以才导致BUG出现？经查生产库中确实用了很多分区，所以导致Bug 20236523 : DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY的出现。 #统计分区表个数，这里只统计了业务用户 col OWNER for a40 select OWNER,count(*) from DBA_PART_TABLES group by OWNER; OWNER COUNT(*) ---------------------------------------- ---------- BMCDB1 51 BMCDB3 64 #统计分区表分区个数，这里只统计了业务用户 col TABLE_OWNER for a40 select TABLE_OWNER,count(*) from DBA_TAB_PARTITIONS group by TABLE_OWNER; TABLE_OWNER COUNT(*) ---------------------------------------- ---------- BMCDB1 881 BMCDB3 4048 3.5 论证：解决方案与效果 exp代替expdp，时间指标来看性能提升了22.5倍。也是当前各方人员都愿意接受的方式。 expdp 04:26:22 exp 00:12:00 实现方法记录 expdp 04:26:22 expdp \'sys/bhlbmc32 AS SYSDBA\' directory=dump dumpfile=expdp_bhl_schemas_${date}_%U.dmp schemas=BMCDB1,BMCDB2 METRICS=Y TRACE=480300 parallel=12 cluster=no logfile=expdp_bhl_schemas_${date}.log exp 00:12:00 exp userid=\"sys/bhlbmc32@bmcCO1 as sysdba\" owner=BMCDB1,BMCDB2 direct=y recordlength=65535 buffer=1048576000 file=/oracle/app/oracle/dump/BMCDB1.20200411.dmp log=/oracle/app/oracle/dump/BMCDB1.20200411.log 总结： 遇到Oracle BUG 也不要害怕。明白BUG不能处理的原理或者逻辑。我们来用我所学的知识来绕过这BUG也是可以达到解决问题的效果的。本文解决的思路：用exp代替expdp。把sql命令处理方式绕过。其实类似于用TABLE ACCESS FULL来代替TABLE ACCESS BY INDEX ROWID解决思路。