% Blocks changed per Read:    3.44    Recursive Call %:    64.76
 Rollback per transaction %:   16.60       Rows per Sort:  6670.54
Rollback per transaction值高么?都只是说高了不好,但多少算高希望高人指点下,
还有Rows per Sort值,谢谢了。。

解决方案 »

  1.   

    这个rollback确实有些高,你想想rollback是什么都没有做,但是却用了很多的资源,这样的操作确实是很不好,不过有些rollbakc是错误到导致的,有的是应用的逻辑导致的,检查一下你们的具体状况,为什么有这么高的rollback
      

  2.   

    我用了临时表,创建临时表的sql最后一句是on commit delete rows;
    但是在commit之前有truncate这张临时表的操作,是不是这两个问题造成
    Rollback per transaction值太高?
      

  3.   

    这份报告数据是在一个时间段里的性能数据分析得出的,不只是由你当前的操作而引起的。打个比方:你开始收集性能数据是在当天的8:00,你第二次收集数据是在当天的9:00,那么,这些分析得出的数据就是从8:00-9:00这一段时间内的性能数据的分析。而在这一段时间内,既使你只执行了turncate与commit两个操作,你也不能说这个分析数据就是针对你所做的那两个操作的结果。因为,在这一段时间内,oracle系统本身还要做很多事情。而这些事情也会影响到你的分析结果。
      

  4.   


    应该不是这个问题,这里rollback,临时表不是用rollback来实现的。 是用临时表空间和分隔的临时表空间段来实现的。
      

  5.   


    不是truncate的问题,应该是你的一些业务应用的异常导致的oracle自动回滚或者一些sp执行失败导致的rollback。
    你才64%左右,还可以的,我们这里一度达到了83%。建议你:用工具跟踪一下,什么时间段这个值比较大,再查查这个时候经常执行什么SQL语句或者调度执行了啥job任务。