19c做好这件事，大幅提升Data Pump工作效率

expdp是Oracle 10g引入的数据导出工具，能够提供并行、压缩及元数据导出等更多的功能，在后续的版本中逐渐替代了传统的数据导出工具exp，是数据库开发运维常用的工具之一。在我的印象中，这个工具除了诸如大量的分区表等数据库对象较多的场景会出现对象解析慢的情况之外，一直运行都比较稳定。

但是近期客户在上线过程中发现一个expdp导出的性能问题，导出15g的数据用了10多分钟，比以往明显的慢不少。

问题的分析和定位比较简单，由于这个系统还没有上线，业务负载几乎为0，我们从采集的问题时间段AWR中TOP SQL部分很容易发现了下面这条语句：

这条语句执行928次，单次执行时间0.74s，总计耗时689秒(和客户反馈的导出时间基本吻合)，调用模块正是Data Pump Worker，因此这条语句是重点怀疑对象。

根据SQL ID dqpwrs34cbf54找到SQL文本，发现是查询系统视图v_$open_cursor， 

SELECT COUNT(*) FROM sys.v_$open_cursor WHERE sid = SYS_CONTEXT('USERENV', 'SID') AND cursor_type = 'OPEN_PLSQL';

这个问题和已知Bug 28771564中记录的故障现象匹配，该Bug影响12.2.0.1以上版本，在20.1版本中修复。针对这个Bug，Oracle MOS中给出了针对相关版本的补丁。

事实上，Oracle还专门出了一个文档Doc ID 2819284.1 (Data Pump Recommended Proactive Patches For 19.10 and Above)，针对19.10及以上版本的Data Pump工具，推荐一系列主动性补丁。比如19.22版本，推荐的Merge Patch  36092868中修复了多达172个Bug，建议大家可以核查自己的环境，必要的时候安装上这个补丁，以提升expdp/impdp的性能并规避已经发现的问题，减少踩坑的概率。

这里挑选几个和性能相关的Bug，供大家参考。

28771564: DATAPUMP EXPORT INVOKED BY A PRIVILEGE USER EXECUTES A QUERY FOR V$OPEN_CURSOR

26565187: DATA PUMP EXPORT PERFORMANCE IS MUCH SLOWER IN 12.2

32370367: EXPDP IN 19.7 THREE TIMES SLOWER THAN IT WAS IN 11.2.0.4

32421259: DATAPUMP EXPORT OF LARGE DATABASE TAKING TOO LONG TO COMPLETE AS COMPARED TO EXPDP

31668026: DATA PUMP EXPORT IGNORES ESTIMATE=BLOCKS

这篇短文一方面介绍了这个影响范围广泛的Bug建议大家在自己的环境中复查，另一方面也展示了Oracle问题的常见分析思路，就是从AWR入手，根据发现的蛛丝马迹层层剖析，最终找出根本的原因所在。

接触国产库之后才深有体会，作为Oracle DBA是幸福的，不仅提供了AWR等详细的素材用于问题的分析诊断， MOS知识库中还记录了海量的故障案例可供参考和对比，帮助用户快速定位和解决问题。反观国产库，在运行时的数据采集和数据库指标上还存在较大的差距，文档和知识库更是相差甚远，要走的路还很长。

大家在运维数据库的时候还遇到什么问题，欢迎关注留言，一起来说道说道！