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

 

 

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

 

简述：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解决思路。

 

 

########################################################################################

版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!【QQ交流群：53993419】

QQ：14040928 E-mail：[e-mail]

本文链接： https://blog.csdn.net/lovehewenyu/article/details/109478203

#######################################################################################