也说一下Oracle CPU Time[转]

http://www.cnblogs.com/rootq/archive/2008/11/11/1331267.html

http://www.itpub.net/thread-1720244-1-1.html

DB Time 就是DB运行所需总时间，是按CPU核心数来合计的，如在一个小时内，8核的CPU平均每个运行了40分钟，那么DB Time就是8*40＝320分钟。
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的语句，他们是否应当有这么大的消耗，他们是否应当执行这么多的次数。