一次ORA-4030问题诊断及解决（三）

核心提示：在报表数据库的后台alert文件中发现了这个错误，简单记录一下问题的诊断和解决过程，一次ORA-4030问题诊断及解决（三），数据库版本9204 for Solaris sparc64， 寻找产生问题的真正原因，而真正的来源数据库版本是10203，发现了这个信息，在第一篇文章中，定位了问题并且找到了解决方法;在第二篇文

在报表数据库的后台alert文件中发现了这个错误，简单记录一下问题的诊断和解决过程。数据库版本9204 for Solaris sparc64。

寻找产生问题的真正原因。

在第一篇文章中，定位了问题并且找到了解决方法;在第二篇文章中，找到了导致源数据库和目标数据库执行计划不同的原因。

但是到目前为止，还没有找到这个问题产生的真正原因。

首先理一下思路，根据第一篇文章的描述，产生ORA-4030问题的原因是由于一个大数据量的插入语句选择了一个十分糟糕的执行计划。而导致Oracle选择了这个执行计划的直接原因是由于列的统计信息出现了错误。而在第二篇文章中，可以确认由于源数据库的版本为9201，没有使用列统计信息中的DENSITY列，所以没有引发这个问题。而在目标数据库版本为9204，Oracle使用了统计信息列DENSITY的值，所以Oracle认为访问ORD_HIT_COMM表且通过ENABLE_FLAG列进行限制，只会返回1条记录，这就导致了Oracle产生了一个错误的离谱的执行计划。

现在的问题是什么导致了源数据库错误统计信息的产生。

这就需要检查源数据库数据和统计的来源。因为在源数据库9201上直接收集统计信息，是不会得到这种DENSITY的。

经过检查发现这个9201的源数据库仍然不是数据的真正源头，而真正的来源数据库版本是10203。

发现了这个信息，那么问题的产生就不奇怪了。

看一下10203上这张表的统计信息：　　

　　　SQL>SELECTCOLUMN_NAME,NUM_DISTINCT,NUM_NULLS,DENSITY,NUM_BUCKETS,HISTOGRAM
　　2FROMUSER_TAB_COLUMNS
　　3WHERETABLE_NAME='ORD_HIT_COMM'
　　4ANDCOLUMN_NAME='ENABLE_FLAG';
　　COLUMN_NAMENUM_DISTINCTNUM_NULLSDENSITYNUM_BUCKETSHISTOGRAM
　　----------------------------------------------------------------------
　　ENABLE_FLAG202.8355E-072FREQUENCY