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

核心提示： 而且从920导入的统计信息可以看到，虽然直方图的统计信息被导入，一次ORA-4030问题诊断及解决（三）(3)，但是USER_TAB_COLUMNS中的NUM_BUCKETS列的值为1，也就是说920中优化器根本不会去考虑直方图信息，手工在920环境上重新收集统计信息，一旦10g的统计信息

而且从920导入的统计信息可以看到，虽然直方图的统计信息被导入，但是USER_TAB_COLUMNS中的NUM_BUCKETS列的值为1，也就是说920中优化器根本不会去考虑直方图信息，而是直接通过NUM_DISTINCT和DENSITY的值来确定执行计划和返回记录数。

对于9201版本，Oracle都使用NUM_DISTINCT的值，也就避免了问题的产生。而在9204中，Oracle使用了DENSITY的值，而这个值并不是9204版本的DBMS_STATS包生成的统计信息，而是从10g环境中导入的，且这个值在10g的FREQUENCY类型的统计信息中已经改变了计算方法，使得计算结果比920环境中要小得多，从而导致了9204上错误执行计划的产生。

显然，整个问题完全是由于版本差异造成的。这个问题说明在将10g的表导入到920环境中，最好不要导入统计信息。

在导出阶段或在导入阶段设置STATISTICS = NONE，避免10g的统计信息导入到920环境中，在导入过程结束后，手工在920环境上重新收集统计信息。

一旦10g的统计信息被导入到920环境中，就必须重新收集统计信息：　

　　　SQL>SELECT*FROMV$VERSION;
　　BANNER
　　----------------------------------------------------------------
　　Oracle9iEnterpriseEditionRelease9.2.0.4.0-64bitProductionPL/SQLRelease9.2.0.4.0-Production
　　CORE9.2.0.3.0Production
　　TNSforLinux:Version9.2.0.4.0-Production
　　NLSRTLVersion9.2.0.4.0-Production
　　SQL>SELECTCOLUMN_NAME,NUM_DISTINCT,NUM_NULLS,DENSITY,NUM_BUCKETS
　　2FROMUSER_TAB_COLUMNS
　　3WHERETABLE_NAME='ORD_HIT_COMM'
　　4ANDCOLUMN_NAME='ENABLE_FLAG';
　　COLUMN_NAMENUM_DISTINCTNUM_NULLSDENSITYNUM_BUCKETS
　　-------------------------------------------------------------------------
　　ENABLE_FLAG202.8355E-071
　　SQL>EXPLAINPLANFOR
　　2SELECT*FROMORD_HIT_COMMWHEREENABLE_FLAG='1';
　　已解释。
　　SQL>SELECT*FROMTABLE(DBMS_XPLAN.DISPLAY);
　　PLAN_TABLE_OUTPUT
　　----------------------------------------------------------------------------------------
　　----------------------------------------------------------------------
　　|Id|Operation|Name|Rows|Bytes|Cost|
　　----------------------------------------------------------------------
　　|0|SELECTSTATEMENT||1|744|9817|
　　|*1|TABLEACCESSFULL|ORD_HIT_COMM|1|744|9817|
　　----------------------------------------------------------------------
　　PredicateInformation(identifiedbyoperationid):
　　---------------------------------------------------
　　1-filter("ORD_HIT_COMM"."ENABLE_FLAG"='1')
　　Note:cpucostingisoff