Oracle DB Time 解读

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

一、Oracle DB Time

由上图可知:

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

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

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

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

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

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

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

调整系统时,将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  

从上图可知,在自然流逝时间内,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

从上图可知, 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、首要等待事件

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

4、主机CPU负载

上图为主机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、时间统计模型

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

6、操作系统统计信息

以上为操作系统统计信息截图 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) 热对象的分区以及索引分离,反向索引设计等

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云上大文件传输

Windows TCP: TCP接收窗口自动调谐(Auto-Tuning)原理介绍

TCP连接上的吞吐量可以通过发送和接收应用程序、TCP的发送和接收实现以及TCP对等体之间的传输路径来限制。在本文我将介绍TCP接收窗口及其对TCP吞吐量的影响...

7926
来自专栏沃趣科技

Oracle压缩黑科技(二)—压缩数据的修改

原文链接 https://www.red-gate.com/simple-talk/sql/oracle/compression-in-oracle-part-...

2816
来自专栏张戈的专栏

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

昨天在公司微信群,CTO 分享了这个消息,对运维来说以后基于 TCP 协议的后端业务的高可用又多了一个新的选择,实在是棒极了! 一直以来,Nginx 并不支持 ...

3065
来自专栏简书专栏

基于Excel2013的数据导入

Excel2013下载网盘链接: https://pan.baidu.com/s/1MdF2pTxlJqZMqILcW2PeBA 密码: rxuv 这个安装包...

2492
来自专栏高性能服务器开发

从零学习开源项目系列(二) 最后一战概况

这份代码我也是无意中来自一个朋友,据他说也是来源于互联网,服务器端代码原来是linux版本的,但被厉害的大神修改成可以在Windows上运行。(如果不小心侵犯了...

1782
来自专栏黑白安全

WEB访问日志自动化分析浅谈

最近经常需要分析WEB访问日志,从中发现非法请求,然后做相应安全检查,为了方便,所以写了一个日志分析平台,支持提交iis,apapche,tomcat,ngni...

1602
来自专栏大数据和云计算技术

Omega系统简介

1.背景 Google的论文Omega:flexible,scalable schedulers for large compute clusters中把调度分...

3945
来自专栏木子昭的博客

Python3简单实现多任务(线程/协程篇)线程多任务实现1:直接使用Thread创建线程线程多任务实现2:定义类继承threading.Thread,然后重写run方法(run方法相当于功能函数)协

写在前面 上一篇文章[Python3简单实现多任务(多进程篇)]已经介绍了python多进程实现多任务的简单实现方法; 这次讲一讲python创建多任务另外两种...

3516
来自专栏FreeBuf

LoadLibrary:一款能够允许Linux程序从DLL文件中加载或调用函数的工具

介绍 今天给大家推荐的这个代码库将允许原生Linux程序从一个WindowsDLL文件中加载或调用功能函数。下面是一个简单的演示示例,我将Windows Def...

3268
来自专栏Jerry的SAP技术分享

Chrome开发者工具关于网络请求的一个隐藏技能

这个隐藏技能的背景是,最近出于学习目的,我写了一个百度贴吧的网络爬虫,专门爬取一些指定主题的贴吧帖子。

1421

扫码关注云+社区

领取腾讯云代金券