Oracle DB Time 解读

女爷i 2022-06-13 00:21 204阅读 0赞

Oracle DB Time是Oracle数据库在时间维度上剖析性能的一个重要指标，通过逐级分解该指标，定位到浪费资源或者资源争用的首要事件上，从而通过减少等待以及最小化每个请求的使用资源来达到优化的目的。本文主要讲述Oracle DB Time，以及给出示例演示Oracle DB Time。

## 一、Oracle DB Time ##

![这里写图片描述][SouthEast]  
由上图可知：

DB Time(请求时间)= DB Wait Time（DB等待时间）+ DB CPU Time（DB CPU服务时间）

上述等式中右边DB等待时间不包括后台进程上CPU开销的时间以及前台进程非空闲等待时间。

优化不仅仅是减少等待。它旨在改善最终用户的响应时间或最小化每个请求使用的平均资源。有时候这些需要一起进行调整，但在其他情况下，有权衡。例如，使用并行查询，并行查询或者并行DML则是更多的利用系统资源来达到快速完成事务或完成查询等相关业务。一般来说，可以调整的方式是减少或避免对系统资源的长时间占用或过度消耗。一旦当资源的占用减少，也就意味着资源可以服务更多的请求来达到提高吞吐量的目的。

由上图可知等待时间是所有等待各种数据库实例资源的总和。 CPU时间是实际工作在请求上花费的时间的总和。这些时间不一定由一个等待和一个CPU时间块组成。通常，进程将经历较短的DB资源等待，然后在CPU上短暂运行，并重复执行此操作。

因此优化包括减少或消除数据库资源等待时间并减少CPU时间。此定义适用于任何应用程序类型，在线事务处理（OLTP）或数据仓库（DW）。

注意：一个非常繁忙的系统显示更长的DB CPU时间，这可能会膨胀其他时间。

## 二、CPU和等待时间调整维度 ##

![这里写图片描述][SouthEast 1]

调整系统时，将CPU时间与系统的等待时间进行比较很重要。通过比较CPU时间与等待时间，您可以确定有多少时间是花在有用的工作以及有多少时间花在等待其他进程可能持有的资源上。作为一般规则，CPU时间占优势的系统通常比等待时间占优势的系统需要更少的调整。但是，CPU使用量过大可能是由严重的SQL语句引起的。等待时间到CPU时间的比例总是趋于随着系统负载的增加而增加，等待时间的急剧增加是争用的征兆，并且必须寻求良好的可扩展性。

当等待时间的增加表明资源争用趋于严重，向节点或节点添加更多的CPU来提高性能，收效甚微。相反，随着负载增加，CPU时间的比例不会显著下降的系统可以更好地扩展，并且最有可能从添加CPU或实际应用集群（RAC）实例中受益。

注意：如果CPU时间部分是前五名事件之一，则自动工作负载存储库（AWR）和Statspack报告显示CPU时间以及前5个事件部分中的等待时间。

## 三、DB Time案例解读 ##

### 1、AWR报告头部 ###

--环境
    SQL> select 'Leshami' Author,'http://blog.csdn.net/leshami' Blog,
      2  '645746311' QQ from dual;                                   
    AUTHOR  BLOG                         QQ                          
    ------- ---------------------------- --------- 
    Leshami http://blog.csdn.net/leshami 645746311

![这里写图片描述][SouthEast 2]  
从上图可知，在自然流逝时间内，10分钟，DB层调用花费的时间为432.12分钟。也即是说是自然时间的43倍左右，数据库处于繁忙状态。

当前数据库逻辑CPU为8个，因此每CPU平均服务时间为432.12/8=54.015min

按前面DB Time的描述，DB Time = DB Wait Time + DB CPU Time 因此 54.015min需要进一步确认是否为真实的使用率。

### 2、Load Profile ###

![这里写图片描述][SouthEast 3]  
从上图可知，  
DB Time(s) 行，每一个自然时间秒，DB Time对应为43.1s，据此推算43.1\*10.02\*60/60 约等于头部的DB Time 432.12分钟。  
DB CPU(s) 行，每一个自然时间秒，CPU的开销为0.1s，即10.02\*60\*0.1=60.12s，也就是说花在CPU上的时间仅仅1分钟左右。  
Redo size 行，每秒产生的redo较多，符合OLTP数据库业务场景。  
Executes与Transactions也表明当前的业务场景为OLTP类型。

### 3、首要等待事件 ###

![这里写图片描述][SouthEast 4]  
上图为首要等待事件，总体来说，数据库等待时间较长。  
write complete waits，等待时间为15629，平均等待29322ms，占据了整个DB Time 的60.28%  
将上述时间加总，总和为25593，与Load Profile计算出来的25851.6s( 43.1\*10.02\*60-60.12) 接近。  
通过上面的计算可知当前的数据库非空闲等待较为严重。

### 4、主机CPU负载 ###

![这里写图片描述][SouthEast 5]  
上图为主机CPU负载情况。  
主机CPU  
在报告期间，“Load Average” begin/end值代表每个CPU的大致运行队列大小，主机负载呈现上升趋势，由1.19上升到4.86  
%User + %System = 1.0 + 0.6 = 1.6 因此空闲的CPU，即%Idle为98.3%  
%WIO表示CPU等待IO占比，此处为7.4%，也就是说当前的系统IO存在瓶颈。

实例CPU  
%Total CPU,该实例所使用的CPU占总CPU的比例—>% of total CPU for Instance  
%Busy CPU，该实例所使用的Cpu占总的被使用CPU的比例—> % of busy CPU for Instance  
%DB time waiting for CPU (Resource Manager)是指当使用了resource manager限制某个用户和会话使用CPU，而产生的等待。会产生resmgr:cpu quantum等待事件，如果产生该等待事件需要和RSRC\_MGR的值结合起来判断。解决方法是需要修改资源限制的plan。  
以下计算结合了操作系统统计信息，数据见后面截图

% of busy CPU for Instance= （DB CPU+ background cpu time) / (BUSY\_TIME /100)= (40.53 + 6.57)/ (7919/100)= 59.4%  
% of Total CPU for Instance = ( DB CPU+ background cpu time)/( BUSY\_TIME+IDLE\_TIME/100) = (40.53 + 6.57)/ ((7,919+471,596) /100) = 0.98%  
%DB time waiting for CPU (Resource Manager)= (RSRC\_MGR\_CPU\_WAIT\_TIME/100)/DB TIME

### 5、时间统计模型 ###

![这里写图片描述][SouthEast 6]  
上图为时间统计模型。  
sql execute elpased time时间占主导，即时间耗用主要是在SQL执行上面。  
这些SQL的执行对应得等待事件见前面的Top Event，也就是说等待和争用比较突出。  
注意该时间模型中的指标存在包含关系所以存在Time Model Statistics加起来超过100%情形。

### 6、操作系统统计信息 ###

![这里写图片描述][SouthEast 7]  
以上为操作系统统计信息截图  
IO等待的时间为35287厘秒

### 7、操作系统层面监控 ###

Device: rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
    sdb       0.00   142.00   15.00  230.00   288.00  1116.00    11.46     3.94   16.16   4.08 100.00
    sda       0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
    dm-0      0.00     0.00    0.00   12.00     0.00    48.00     8.00     0.35   29.00   2.50   3.00
    dm-1      0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
    dm-2      0.00     0.00   16.00  360.00   296.00  1068.00     7.26     4.38   11.71   2.66 100.00
    
    Device: rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
    sdb       0.00   142.00   12.00  218.00    96.00  1060.00    10.05     3.33   13.98   4.35 100.00
    sda       0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
    dm-0      0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
    dm-1      0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
    dm-2      0.00     0.00   14.00  360.00   160.00  1060.00     6.52     4.36   11.36   2.67 100.00

操作系统层面%util为100，await时间为平均服务时间svctm4倍左右，即IO存在超负荷运转，这与AWR中前台等待进程等待相呼应。

### 8、初步结论 ###

1) 通过首要等待事件，以及OS层面观察，当前的主要瓶颈在IO。  
2) 如未开启异步IO，可以考虑开启异步IO (OS及DB层面同时开启)  
3) 优化SQL以减少过多的IO负载，同时也可以考虑优化SQL所在的包，存储过程  
4) 热对象的分区以及索引分离，反向索引设计等

[![DBA牛鹏社(SQL/NOSQL/LINUX)][DBA_SQL_NOSQL_LINUX]][DBA_SQL_NOSQL_LINUX_DBA_SQL_NOSQL_LINUX]

![这里写图片描述][1493001734_6055.jpg]

[SouthEast]: /images/20220613/a85e0ddce34342e7abd8748831740cf7.png
[SouthEast 1]: /images/20220613/d5dc2cf3df50451ab7ae87f6a4975ba3.png
[SouthEast 2]: /images/20220613/cdfeb4d4a40948aaa7061d610fe5f4ed.png
[SouthEast 3]: /images/20220613/2a1a619a3af2421bbf5051c96af2f346.png
[SouthEast 4]: /images/20220613/a69ffc4c583a40ebb231c96cf753e4c0.png
[SouthEast 5]: /images/20220613/5c12252ad4244e508bd046bd604911c5.png
[SouthEast 6]: /images/20220613/110133796b07451f9c4bfe4f4ef11731.png
[SouthEast 7]: /images/20220613/128c33c320604246be26a4653178e0d9.png
[DBA_SQL_NOSQL_LINUX]: http://pub.idqqimg.com/wpa/images/group.png
[DBA_SQL_NOSQL_LINUX_DBA_SQL_NOSQL_LINUX]: /images/20220613/311a7622b9f045e8a761185b3754d087.png
[1493001734_6055.jpg]: https://img-my.csdn.net/uploads/201704/24/1493001734_6055.jpg