kamus在他的blog 10gRAC培训 – 2 and last。说到了这个cpu time，具体可以看正文以及下面我与他的留言，他的意思其实就是：
CPU Time相对于其它等待事件，应当先忽略CPU Time，处理其它等待事件。而且cpu time高一般代表是好事情，因为系统并没有把时间耗费在Wait上。Elapsed Time = CPU Time + Wait Time，所以甚至我们可以说CPU Time越高越好。
不是说他的不对，只是比较觉得这句话太容易误导别人，所以，给一些补充建议，我同意如果有很明显的其它事件，而cpu time不明显的时候，可以优先处理其它事件。但是，还有以下2个地方需要注意：
1、cpu time高一般代表系统的逻辑读大，或者是高计算型的东西，如case函数，decode函数，自定义的计算类型函数等等，把cpu给耗光了，但是这个时候可能根本没有其它等待事件。这样是否证明这个系统很好呢？很可能是，非常不好，因为他很有可能没有必要有这么多的逻辑多，或者是，没有必要有这么多的cpu密集型计算就可以完成的任务，现在消耗这么CPU Time就是不正常的，很容易导致系统负载异常。
2、至于wait time，比如OLTP环境上最典型的db file sequential read引起的等待，是因为发生了物理io而引起的，而很多时候，物理读是随逻辑读增加而增加的，而逻辑读可能会导致cpu time高，也就是说，cpu time与wait time一般是同时增加的。特别是比较高访问量，大数据量，大SGA的系统，逻辑读与物理读都比较高，除了cpu time与db file sequential read，可能不会有很明显的其它等待事件，而优化的结果可能是cpu time与wait time同时减少。
既然说到了db file sequential read，也解释一下这个事件，与cpu time一样，很多时候说明系统是比较正常的，一个优化非常良好的系统，很可能第一个等待事件就是它。因为没有一个系统，不会发生任何物理IO，既然有物理IO，当然db file sequential read就是最好的了，一般表示读数据正常。同样的理由，db file sequential read大了，也可能预兆系统有不该有的物理读发生了。
如一个看起来很正常的sql语句，单个语句效率看起来并不差，执行时间已经小于0.01秒。假定原来逻辑读每个语句平均是100个，物理读平均10个，执行次数每小时50万次，优化完成以后，逻辑读降低为平均50个，物理读平均5个，那么，每小时降低的逻辑读总量就是50*50w=2500w个，降低的物理读为5*50w=250w个。那么再假定每个cpu每秒处理100000个逻辑读就达到了极限，每个物理读需要等待8ms，那么，就可以减少约2500w/100000*3600=7%的CPU使用率（单CPU），可以减少250w*8ms=20000秒的总io wait time。
同理，如果能采用同样的方法，减少执行次数从每小时50w到每小时25w，则收到的效果是一样的。
评价这个cpu time与db file sequential read是否正常，需要很多调优的经验，不过，需要记住的是，任何情况下，不要绝对的说好还是不好。最好的方式就是从statspack或者是awr上看看，排在cpu time，或者是物理读top的语句，他们是否应当有这么大的消耗，他们是否应当执行这么多的次数。
上一篇： « 杂事·琐事·平常事·烦心事（续）
下一篇： 跨用户或者是DB导出/导入统计数据 »
- 发表评论
