过滤条件条件不一样，执行计划却不一样，效率相差近4倍

对于装了db2客户端的Cognos应用，只需要bind db2clipk.bnd collection NULLIDRA就算是打开REOPT了吗？貌似不起作用，report执行的时候db2pd都没有监控到，执行计划也没变。收起

第一个方法，是先runstats再重写查询，然后run吧？
第二个方法试过了，确实管用，估计值完全准确，执行时间了三倍多。

还有个问题，假如是动态SQL该怎么办？我们实际情况针对T_GEO_DIM还有个过滤条件，且放在了where条件的第一位：
"IOT_SHORT_NM" =cast(? as VARCHAR(20))
我试了下，如果是这样，statistical view或者MQT就用不上了，这种情况下该怎么办？

附件是带参数的执行计划：

{:2_44:} 带参数SQL有以两个相同列作为过滤条件的情况，貌似确实有点stupid，但目前没办法，因为Cognos生成的就是这样。。收起

回复 3# mdkii

1） 这个查询结果出来是688344，确实比1122大很多。不光如此，而且根据重写的SQL来看，Europ中的这一步也和统计出来的有差距。
SELECT count(1)
               FROM DWDM.T_GLOBALSR_FCT AS Q5, DWDM.T_GEO_DIM AS Q18
               WHERE (Q5.ACTIVE_REC = 'Y')  AND
                       (Q18.GEO_DIM_UID = Q5.WORK_GEO_DIM_UID) AND
                       (Q18.IOT_SHORT_NM = 'Europe') and
                       (Q18.IMT_SHORT_NM IS NULL OR Q18.IMT_SHORT_NM IN
                       ('ADJ', 'Benelux', 'BeNeLux', 'CEE', 'DACH', 'France',
                       'France,NWA', 'Italy', 'Nordic', 'Spain,Portugal,Gre',
                    'UKI'))
数据量为1037592.而执行计划为492424。对于Japan这个plan中针对Q18（T_GEO_DIM）表的过滤，最终结果应该是3，但Estimated number of rows:         0.0715713。
造成估计值少的原因是什么呢？

2） 问题在production环境，selectivity没开，暂时没办法测试。另外Japan的数据确实比Europ的数据要少。

3） 附件是exfmt的结果。
收起

DB2很难给予在任何情况都是最优的执行计划给你，所以它只能给它认为最优或者相对次优好实现的执行计划给你。

对于数据量的偏差，根据它的统计信息模型可能计算有误。以前我们经常碰到，在交易量不大的情况下产生NLJOIN的执行计划得到的执行时间反而远远大于数据量大但是通过HASH JOIN得到的执行时间。收起

回复 4# duanzhihui
    谁说的？收起

我不是知道 cogonos是怎么连DB2的。我猜测应该是cli方式，如果是cli，那么除了 bind db2clipk.bnd collection NULLIDRA外还要执行一下动作：

Specify either REOPT keyword or CurrentPackageSet keyword in the db2cli.ini file.
REOPT = 2 | 3 | 4
2---REOPT NONE (default value)
3---REOPT ONCE
4---REOPT ALWAYS
CurrentPackageSet="NULLID" | "NULLIDR1" | "NULLIDRA"
Setting REOPT = 4 is equvelent to CurrentPackageSet = "NULLIDRA". If both REOPT and CurrentPackageSet keywords are specified, CurrentPackageSet takes precedence.

设置好了之后，断开重新连一下以确保设置生效。收起

你可以尝试打开 reopt always 选项。
http://www.ibm.com/developerwork ... ticle/dm-1011reopt/
这里面已经写得很详细了。
建议你打开selectivity=all的选项，这样对于复杂SQL可以加一些hint。收起

thanks，明天试试收起

0.07 是这么算的。
294 * 0.0102041 * 0.0238571。
从你的描述看，条件1 ： Q18.IOT_SHORT_NM = 'Japan' 和条件2 （Q18.IMT_SHORT_NM IS NULL OR Q18.IMT_SHORT_NM =  'Japan') 是相关的。而优化器确认为两者不相关，所以低估了card值。你可以试试两个做法：
1、改写一下where条件,然后再收集一下column group statistics。

（ IOT_SHORT_NM = 'Japan' and IMT_SHORT_NM = 'Japan') or ( IOT_SHORT_NM = 'Japan' and IMT_SHORT_NM is null )
runstats on table DWDM.T_GEO_DIM on columns (( IOT_SHORT_NM, IMT_SHORT_NM ))
 with distribution on all columns and detailed indexes all

2、创建一个statistical view 看看能不能修正一下card的估计值。

create view V_GEO_DIM as select * from T_GEO_DIM where IOT_SHORT_NM = 'Japan'  and ( IMT_SHORT_NM IS NULL OR IMT_SHORT_NM =  'Japan') 
alter view V_GEO_DIM  enable query optimization;
runstats on table  V_GEO_DIM  on all columns with distribution;

收起

回复 2# jlandzpa


    SQL是Cognos前端生成的，没办法重写。收起