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

核心提示： 分析9204上的执行计划，没有什么特殊的地方，一次ORA-4030问题诊断及解决（二）(5)，下面在看看源数据库9201上的事件分析结果：$sqlplusshgovSQL*Plus:Release9.2.0.1.0-Productionon星期三4月3018:52:162008Copyri

分析9204上的执行计划，没有什么特殊的地方，下面在看看源数据库9201上的事件分析结果：　

　　　$sqlplusshgov
　　SQL*Plus:Release9.2.0.1.0-Productionon星期三4月3018:52:162008
　　Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.

请输入口令:

连接到:　　

　　　Oracle9iEnterpriseEditionRelease9.2.0.1.0-Production
　　WiththePartitioning,OLAPandOracleDataMiningoptions
　　JServerRelease9.2.0.1.0-Production
　　SQL>altersessionsetevents'10053tracenamecontextforever,level1';

会话已更改。　

　　　SQL>explainplanforselect*fromord_hit_commwhereenable_flag=1;

已解释。　　

　　　SQL>host
　　$more$ORACLE_BASE/admin/orcl/udump/orcl_ora_17582.trc
　　/oracle/admin/orcl/udump/orcl_ora_17582.trc
　　Oracle9iEnterpriseEditionRelease9.2.0.1.0-Production
　　WiththePartitioning,OLAPandOracleDataMiningoptions
　　JServerRelease9.2.0.1.0-Production
　　ORACLE_HOME=/oracle/app/product/9.2.0
　　Systemname:SunOS
　　Nodename:jssf4900a
　　Release:5.10
　　Version:Generic_118822-23
　　Machine:sun4u
　　Instancename:orcl
　　Redothreadmountedbythisinstance:1
　　Oracleprocessnumber:187
　　Unixprocesspid:17582,image:oracle@jssf4900a(TNSV1-V3)
　　***2008-04-3018:53:16.849
　　***SESSIONID:(187.390)2008-04-3018:53:16.848
　　QUERY
　　explainplanforselect*fromord_hit_commwhereenable_flag=1
　　***************************************
　　PARAMETERSUSEDBYTHEOPTIMIZER
　　********************************
　　OPTIMIZER_FEATURES_ENABLE=9.2.0
　　OPTIMIZER_MODE/GOAL=Choose
　　.
　　.
　　.
　　_CPU_TO_IO=0
　　_PRED_MOVE_AROUND=TRUE
　　***************************************
　　BASESTATISTICALINFORMATION
　　***********************
　　TablestatsTable:ORD_HIT_COMMAlias:ORD_HIT_COMM
　　TOTAL::CDN:1681983NBLKS:89780AVG_ROW_LEN:733
　　_OPTIMIZER_PERCENT_PARALLEL=0
　　***************************************
　　SINGLETABLEACCESSPATH
　　Column:ENABLE_FLACol#:21Table:ORD_HIT_COMMAlias:ORD_HIT_COMM
　　NDV:2NULLS:0DENS:5.0000e-01
　　NOHISTOGRAM:#BKT:1#VAL:2
　　TABLE:ORD_HIT_COMMORIGCDN:1681983ROUNDEDCDN:840992CMPTDCDN:840992
　　Accesspath:tscResc:8636Resp:8636
　　BEST_CST:8636.00PATH:2Degree:1
　　***************************************
　　OPTIMIZERSTATISTICSANDCOMPUTATIONS
　　***************************************
　　GENERALPLANS
　　***********************
　　Joinorder[1]:ORD_HIT_COMM[ORD_HIT_COMM]
　　Bestsofar:TABLE#:0CST:8636CDN:840992BYTES:616447136
　　Final:
　　CST:8636CDN:840992RSC:8636RSP:8636BYTES:616447136
　　IO-RSC:8636IO-RSP:8636CPU-RSC:0CPU-RSP:0
　　PLAN
　　Costofplan:8636
　　Operation...........Objectname.....Options.........Id...Pid..
　　SELECTSTATEMENT0
　　TABLEACCESSORD_HIT_COMMFULL1

现在问题已经很显然了，Oracle分析的时候认为DENSITY是0.5，而不是从统计信息查询处理的结果：2.9971e-07。而使用0.5作为DENSITY的值，显然是可以得到正确的返回记录数的。这个值也是目标数据库删除统计信息，并重新生成统计信息后的值。

看来在9201中Oracle并没有采用统计信息中DENSITY的值，而是使用了1/ NUM_DISTINCT作为DENSITY的值，虽然对于当前的问题，这样使用恰好可以得到“正确”的返回记录数，但是这种方式显然是存在问题的，比如列中包含了大量NULL的情况，这样直接使用1/ NUM_DISTINCT就是不准确的。

而9204中修正了这个bug，使用了统计信息中的DENSITY的值，也就导致了问题的产生。

看来正是由于版本的差异，从而导致了这个问题在目标数据库中暴露了出来。