也说一下Oracle CPU Time[转]
DB CPU是DB真正运行CPU的总时间,即是不包括等待时间。
前台等待基本下包含后台等待,如执行一个UPDATE的SQL,服务器收到此SQL时开始解析,引时DB TIME开始计时,如所需数据字典在内在,则CPU会全程运行解析步骤,这个CPU的时间就是DB CPU,当要更新数据时若发生LATCH争用,这时CPU就要等待,这个LATCH等待是后台等待,此后台等待是前台等待的一部分,当更新完提交事务要写LOG时发生一系列事件,log file sync前台等待事件一次的等待时间包括LGWR后台的写操作时间和通知前台时间,也就是说“log file sync”包括了“log file parallel write”中的后台等待时间。
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的语句,他们是否应当有这么大的消耗,他们是否应当执行这么多的次数。