错误的索引统计信息导致oracle expdp导500多G的大分区表时hang住

1：用expdp导数据，语句如下

expdp system/oracle directory=xxx TABLES=xxx.AC51 dumpfile=xxx_%U.dmp logfile=xxx.log EXCLUDE=index,STATISTICS,constraint parallel=15  compression=ALL cluster=n version=11.2.0.4.0

Note：从语句中看到是不导出表的索引，统计信息和约束的

 

2：数据库hang住

数据库导出4个小时，hang住，停止导出。

  2.1查询导出的进度

select sid,serial# from v$session s,dba_datapump_sessions d where s.saddr=d.saddr;

  2.2查询消耗资源多，长时间runing的sql



  2.3 定位问题

发现一条长时间无法执行完的sql

SELECT NVL((SELECT /*+ NESTED_TABLE_GET_REFS NO_PARALLEL */ 1 FROM "xxx"."AC51" PARTITION("AC51_MAX") WHERE ROWNUM = 1), 0) FROM SYS.DUAL



找到该问题

 

3：问题分析

   3.1 Oracle记录相关的一些信息，当expdp使用network的方式的时候，如果cursor_sharing=similar，可能会因为没有正确的做绑定变量窥探而导致错误的结果，从而导致poor
performance。但这里是本地的expdp方式，并没有使用network。

 

   3.2 运行

SELECT NVL((SELECT /*+ NESTED_TABLE_GET_REFS NO_PARALLEL */ 1 FROM "xxx"."AC51" PARTITION("AC51_MAX") WHERE ROWNUM = 1), 0) FROM SYS.DUAL

发现确实无法出现结果

 

   3.3 查看执行计划

 


 

CBO采用的是index full scan

 

因为他们有一个额外的环境可以测试此表，测试一样的sql，发现可以秒出信息

 

CBO采用的table access full



  两者的执行计划不一样，索引的统计信息出了问题?

  查看索引的统计信息







发现索引的统计的信息确实不正常。

在有问题的sql的加上full的hint，发现查询正常响应。

在出现问题的数据，加入hint强制走table access full



4: 解决方案

因为这条表的size大于500G，重新收集统计信息，时间太长。所以让他从测试的库上导出“正确”的统计信息，复制到有问题的表上。然后重新运行expdp。结果运行正常。