请帮我看看这份StatspackReport,看看有哪里需要调节和改进。这份报告的时间区间里系统正在进行批量处理,每天的批处理所需时间比较不稳定。该报告的地址如下:http://blog.csdn.net/abyanbing/archive/2009/12/23/5065582.aspx

解决方案 »

  1.   

    没什么太大问题;
    1, 系统压力不大。 每秒事务数只有0.69
    2, 主要的时间消耗在CPU, 这可能会是因为逻辑度过多造成的;
    3, top 5 events中出现了几个单次执行逻辑读上百万的, 可以考虑优化一下。比如调整一下执行顺序, 增加个索引啥的。
      

  2.   

    看了下开头,
    Library Hit   %:   96.73        Soft Parse %:   77.95Library Hit应该在99%左右, Soft Parse应该在95%左右。你这问题太大了,第一步要做的是加大你的共享池。shared Pool Size:       108M       112M
      

  3.   

    查询语句里面为什么每个条件都要trim?
      

  4.   

    其实硬解析过多,这个问题我也意识到了,因为这个系统偏重运用灵活的规则进行数据分析,所以很多分析规则都是字符串拼出来的SQL语句,没有办法绑定变量。顺便问一下,增加共享池效果会很明显吗?
      

  5.   


    因为最终有些数据需要拼成报文发送,所以数据类型基本上都是Char类型的,为了拼报文的时候占位方便。
      

  6.   


    trim这类东东拿到程序里面去,trim了索引用不了。
      

  7.   


    字符串拼接出来的也是可以的,无论是java还是plsql。plsql的话看一下dbms_sql这个包,java的话方法就多了。不过sql灵活过头的话用了绑定变量也没什么用了