如何解决不同SQL之间的性能冲突？

olive

他也没有多说，只是说按照他的经验，得出的结论就是，不要用734的CBO。

chao_ping

实在没招,就用hint
我这两天调整SQL,主要就是靠它了.
817的CBo,得出的结论还是不好,没有办法,只有强制使用hint.(不过SQL本身不是很复杂.)

biti_rainy

oracle的cbo的选择
毕竟时间和空间代价不能太高
所以：它大部分时间选择的是比较好的方案
极少数时间选择的是不好的方案

任何人都不能确保它选择的是最优的方案
（当然，别拿简单sql来谈论这个问题，呵呵）

olive

例如如何选择index，如何调整SELECT中子句的顺序，如何适当地建立index等。
我曾经碰到过这样的问题，某个report写出来以后发现运行很慢，后来就在某个表加了一个index，运行速度大大加快，可是很快发现另外一个report运行时间变得很慢（都是没有statistics的），唉！

DeepBlue

7的CBO没问题的, 倒是9i的CBO有bug, 小心.

Oracle的CBO要考虑跨OS平台,准确度较低. 几个数据库中MS的最强.

olive

刚才已经找出来所有的plan，一共找了3000多种组合，最后剩下219种不同的plan，现在正在运行，设定的terminate条件是2分15秒。现在为止运行了6种，最好的纪录是58.75秒，对应语句如下。看看它加的+0, ||''之类，这活儿还真不是人干的。
select tacct.body_nb bodynb,
       tacct.nb acctnb,
       tacct.actype_ty,
       tacct.blccl_nb blcclnb,
       tacct.cstgrp_nb cstgrpnb,
       tprprty.propty_cd proptycd,
       tprprty.nb prprtynb,
       tbtchdt.nb_walk_order nbwalkorder
  from tdelpnt,
       tbtchdt,
       taddrid,
       tacct,
       tprprty,
       tprpacc,
       tbody
where tbtchdt.batch_nb = 269
   AND tbtchdt.sectn_cd = taddrid.sectn_cd || ''
   AND tbtchdt.blccl_nb = tacct.blccl_nb
   AND tbtchdt.cstgrp_nb = tacct.cstgrp_nb + 0
   AND taddrid.cd = tbody.addrid_cd || ''
   AND tacct.body_nb = tbody.nb + 0
   AND tacct.body_nb = tprpacc.body_nb + 0
   AND tacct.nb = tprpacc.acct_nb
   AND tprprty.nb = tprpacc.prprty_nb + 0
   AND tprpacc.dt_end is null
   AND tdelpnt.prprty_nb = tprprty.nb + 0
   AND tdelpnt.in_ocpl = '2'
   AND tprpacc.body_nb = tbody.nb + 0
   AND tdelpnt.prprty_nb = tprpacc.prprty_nb + 0
order by tbody.nb

olive

鉴于已经有语句在一分钟内完成，故将终止条件调整为1分05秒，或当前最好纪录。这样可以缩短测试过程。
但是我发现刚才运行1分14秒的语句现在重新运行只要48秒（两次运行之间plan已经变过了所以应该不是cache的问题），怎么回事？server是我独享的。

machao

我以前碰到过一个6-7个表进行连接要几分钟才出结果,
当时用一个工具来看执行计划,都不能按照
理想的路径执行.
后来我先根据各表的索引表的大小逻辑关系,
人工找出哪二个表应该最先连接,是最优的,
,然后做一个function返回这两个表上的部分数据,
最后在select a.it,a.dd,b.dd,c.f,<function_name> from a,b,c ....
效果不错.
看看对你们有没参考作用.

DeepBlue

最初由 olive 发布
[B但是我发现刚才运行1分14秒的语句现在重新运行只要48秒（两次运行之间plan已经变过了所以应该不是cache的问题），怎么回事？server是我独享的。 [/B]

Plan 应该是不会变的, 你可以选中某句, 不用批运行,直接取下时间, 看下Plan, 我觉得是cache.

btw:你是否把优化智能定为10 了, 优化完时的优化细节窗口注意看下, 可能是限额满了才停下来的, 可能还有其他的写法. 如果是限额满, 可在参数设置中加大.

olive

我说PLAN变过了，意思是指中间曾经运行过采用其他PLAN的语句了。
现在全部运行完了，最好的是34.62秒，我又在server上单独运行了两次，分别为39.90和39。45，看来是稳定的。和CBO（约7秒）还是有相当的距离啊。
我大致看了一下它产生的那么多语句，好像都没有加hint？只是调整了子句的顺序。
最快的语句如下。还有什么招数？
select tacct.body_nb bodynb,
       tacct.nb acctnb,
       tacct.actype_ty,
       tacct.blccl_nb blcclnb,
       tacct.cstgrp_nb cstgrpnb,
       tprprty.propty_cd proptycd,
       tprprty.nb prprtynb,
       tbtchdt.nb_walk_order nbwalkorder
  from tdelpnt,
       tbtchdt,
       tacct,
       tprprty,
       tprpacc,
       tbody,
       taddrid
where tbtchdt.batch_nb = 269
   AND tbtchdt.sectn_cd = taddrid.sectn_cd || ''
   AND tbtchdt.blccl_nb = tacct.blccl_nb
   AND tbtchdt.cstgrp_nb = tacct.cstgrp_nb + 0
   AND tbody.addrid_cd = taddrid.cd || ''
   AND tacct.body_nb = tbody.nb + 0
   AND tacct.body_nb = tprpacc.body_nb + 0
   AND tacct.nb = tprpacc.acct_nb
   AND tprprty.nb = tprpacc.prprty_nb + 0
   AND tprpacc.dt_end is null
   AND tdelpnt.prprty_nb = tprprty.nb + 0
   AND tdelpnt.in_ocpl = '2'
   AND tprpacc.body_nb = tbody.nb + 0
   AND tdelpnt.prprty_nb = tprpacc.prprty_nb + 0
order by tbody.nb