你的cursor_sharing 设的是exact or similiar?

解决方案 »

  1.   

    CBO 需要统计数据选择最佳执行计划。
    使用bind var 主要为了减少硬解析次数 1. 9206 以前的cursor_sharing如果是FORECE 确实是有问题的,这里没有考虑例如倾斜度会改变执行计划的问题,可是9i以后多了一个参数similar,按照oracle的说法这个是 safe literal. 不过bug不少,最好用exact
    2. cbo在某些情况下,使用绑定变量得到的执行计划没有 直接使用数据得到执行计划好,如你所说,使用绑定变量会缺少一些数据分析。
    但是大多数情况,cbo选择的即使不是最优的执行计划,也是很不错的执行计划。而你假如大量不用绑定变量,那就肯定会对系统造成灾难。
    lz可以试使用hint
      

  2.   

    并不一定是绑定变量的总是。有可能大量的查询条件并不多。这个时候使用常量会更好一些。因为var bind会产生很多的soft parse建议你做个statspack 来看看你的系统的瓶颈到底是怎么产生的。然后针对性来进行tuning
      

  3.   

    是不是解析太多了?
    select round((b.value/a.value),2)*100||'%' HardParseRatio
    from   v$sysstat a,v$sysstat b
    where  a.NAME='parse count (total)'
    and    b.NAME='parse count (hard)'
      

  4.   

    其实TOM的expert one on one oracle里面这点讲得很清楚.就像我上面那样说的.首先要清楚软硬解析这两上概念.毕竟软是需要要共享池中寻址的.