statspack中CPU TIME的理解

其中的CPU TIME是Oracle 9i以后引入的，这里其实需要指出的是，调优的第一手资料其实还是从statspack中的这个部分来分析，那么结合我们的top 5的等待事件，我们可以来衡量不同等级的top sql:

1.消耗最多CPU的(逻辑IO比较多的)

2.导致过多物理I/O的(物理IO比较多的)

3.执行次数较频繁的(Execution次数比较多的)

4.执行时间较长的(Elapse time比较长的)

其实在Oracle世界里有一套关于resposne time的分析方法：

Response time=Service time + Wait time

因此在上面的top 5 timed events表格里面我们看见了有Waits和Time (s)两列，分别罗列了我们response time的两大部分，一部分是服务时间由time (s)表示，另外一个部分就是等待时间了由Waits表示。而Time (s)是指花在CPU上的时间，而Waits是花 在等待事件上的总的时间

那么什么是Service time呢？
其实Service time就是CPU为执行该语句花费的时间。
Service Time=CPU Parse + CPU Recursive + CPU Other 三部分组成
CPU Parse是CPU用于分析语句的时间，CPU Recursive是CPU用于语句的递归SQL的时间，CPU Other则就是CPU用于执行语句的真正时间了。

在Statpacks中Instance Activity Stats中就有部分的时间统计信息：

Service time=CPU used by this session

CPU Parse=parse time cpu

CPU Resursive=recursive cpu usage

所以CPU ther=CPU used by this session - parse time cpu - recursive cpu usage

如果执行时间(CPU Other)在整个Service time中占较大的比例，那么下一步就是找出那些造成了最多逻辑IO的SQL语句，可以从statspack报告的SQL ordered by Gets部分找到。

如果分析时间(CPU Parse=parse time cpu)在整个响应时间中占较大的比例，那么下一步就是查找哪些SQL分析过多，这在statspack报告中在SQL ordered by Parse Calls中列出。

如果等待时间(Wait time)在整个响应时间中占较大的比例，并且主要是块读取相关的等待时，下一步就是找出哪些SQL造成了过多的物理读，可以查看statspack报告中的SQL ordered by Reads部分。

比如我们现在从Instance Activity Stats查出一些数据：
Instance Activity Stats  DB/Inst: IRMDB/irmdb  Snaps: 6-7

Statistic                                      Total     per Second    per Trans
--------------------------------- ------------------ -------------- ------------
CPU used by this session                     308,760           71.8         21.3
......
parse time cpu                                    23            0.0          0.0
parse time elapsed                               167            0.0          0.0
......
recursive cpu usage                          307,328           71.5         21.2
......

我们知道CPU Time的total call time%是94.4%
我们就可以看一下：
CPU Time=94%
CPU ther=308,760 - 23 - 307,328 = 1409
CPU ther=1409 / 308,760 * 94% = 0.43%
CPU Parse=23 / 308,760 * 94% = 忽略不计
CPU Recursive = 307,328 / 308,760 * 94% = 93.56%

可以看到原来我们的Recursive call占用了我们大量的CPU时间

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28419/viewspace-616664/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28419/viewspace-616664/