ITPub博客

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

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

原创 Oracle 作者:lovehewenyu 时间:2020-11-03 20:12:16 0 删除 编辑

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


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

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

QQ:14040928 E-mail:dbadoudou@163.com

本文链接:  http://blog.itpub.net/26442936/viewspace-2685693/

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


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26442936/viewspace-2685693/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
10年老鸟,Oracle,Mysql,EMC 存储,NBU备份。微信/电话 18211103995

注册时间:2012-02-03

  • 博文量
    275
  • 访问量
    1353800