与IO相关的等待事件troubleshooting-系列2

Troubleshooting步骤:

Troubleshooting与IO相关的等待

数据库性能调优方面一项关键的方法就是响应时间分析。找出时间都花费在数据库的哪些环节。

时间是性能调优中最重要的属性。用户通过交易或批处理任务的响应时间来感知系统的性能。

Oracle的响应时间分析使用如下公式:

Response Time = Service Time + Wait Time

响应时间=服务处理时间+等待时间

‘服务处理时间’使用‘CPU used by this session’统计数据来衡量。

‘等待时间’则是所有等待事件用时之和。

注:尽管很像,但这个公式绝对不是排队理论的基础公式。

通过分析总体响应时间不同组件的相对影响,可以使用AWR或statspack这样的工具进行性能调优,将调优的精力放到最消耗时间的组件中。

判断IO等待事件的真实重要性

        包括AWR和Statspack在内的许多工具都可以列出最重要的等待事件。Oracle 9i R2的Statspack报告之前的版本包含在了"Top 5 Wait Events"节。

        当看到这样的top等待事件列表,通常就会很容易地开始处理这些等待事件,但往往忽视了首先可以分析下他们对总体响应时间的影响。

        “Service Time”(例如CPU的使用)要远比“Wait Time”更重要,分析这些等待事件不会对节省“响应时间”有帮助。

        因此,应该将top等待事件花费的时间与“CPU used by this session”对比,将调优的精力放到最需要的地方。

        从Oracle 9i R2开始,“Top 5 Wait Events”已经改名为“Top 5 Timed Events”,通过统计session所用的CPU来衡量“Service Time”,并列到“CPU time”中。这就意味着可以更容易、更准确地衡量等待事件对总体“响应时间”的影响,正确地指导接下来的调优方向。

错误理解等待事件的影响:实例

        接下来的两个真实案例说明了为什么需要查看“Wait Time”和"Service Time"两部分,对分析数据库性能的重要性。

实例1:Oracle 9i R2之前的Statspack

        下面是产生自46分钟的两个snapshot之间的Statspack报告“Top 5 Wait Events”节:

Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
direct path read                                    4,232       10,827   52.01
db file scattered read                              6,105        6,264   30.09
direct path write                                   1,992        3,268   15.70
control file parallel write                           893          198     .95
db file parallel write                                 40          131     .63
         -------------------------------------------------------------

        从以上的列表,我们很可能倾向于立即开始查找“direct path read”和“db file scattered read”等待之间的原因,尝试调优他们。这种方法没有考虑到“Service Time”。

        从同一份报告中得到的“Service Time”如下:

Statistic                                    Total   per Second    per Trans
--------------------------------- ---------------- ------------ ------------
CPU used by this session                   358,806        130.5     12,372.6   

        让我们来做一下简单的计算:

'Wait Time' = 10,827 x 100% / 52,01% = 20,817 cs

'Service Time' = 358,806 cs

'Response Time' = 358,806 + 20,817 = 379,623 cs

        如果现在我们来计算所有“Response Time”组件的百分比:

CPU time                    = 94.52%
direct path read            =  2.85%
db file scattered read      =  1.65%
direct path write           =  0.86%
control file parallel write =  0.05%
db file parallel write      =  0.03%

        现在就明显了,与IO相关的等待事件对于总体响应时间来说并不是真正耗时的组件(少于6%),因此解析来的调优应该聚焦在服务处理时间组件上,例如CPU消耗。

实例2:Oracle 10i R2之后的AWR

注意:类似的信息也会显示在Oracle 9i R2以后的Statspack报告:

Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                          Avg
                                                         wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                           33,615          82.0
db file sequential read           3,101,013       7,359      2   18.0 User I/O
log file sync                       472,958         484      1    1.2 Commit
read by other session                46,134         291      6     .7 User I/O
db file parallel read                91,982         257      3     .6 User I/O  

        在AWR中,更容易看到CPU是最耗费时间的,因为CPU组件也包括在“Top 5 Timed Foreground Events”节。从上面的例子,我们能够再次看到等待事件的用时少于20%,家下来的调优重点应该放在服务处理时间的组件上,例如CPU消耗。

(未完待续)

时间: 2024-09-29 23:59:38

与IO相关的等待事件troubleshooting-系列2的相关文章

与IO相关的等待事件troubleshooting-系列4

与数据文件IO相关的等待事件: 接下来的等待事件是与数据文件的IO操作时产生的. 'db file sequential read'         这是一种最常见的IO相关的等待.大多数情况下,他指的是单块读,例如索引数据块或通过索引访问的表数据块,也能在读取数据文件头块时看到这种等待事件.在更早的版本中,这种等待事件也会产生于从磁盘的排序段通过多快读的方式读入Buffer Cache的连续("sequential")缓冲.         如果这种等待事件占据了大部分的等待时间,可

与IO相关的等待事件troubleshooting-系列7

与控制文件IO相关的等待事件:         这种等待事件通常产生于一个或多个控制文件的IO.像redo日志切换和检查点事件,都会产生频繁的控制文件访问.因此调优这些实践可以间接地影响这种等待事件. 'control file parallel write'         这种等待事件通常发生于服务器进程正在更新所有控制文件副本的时候.如果这种等待事件占据大部分事件,那么需要检查所有控制文件副本在IO路径(控制器,物理磁盘)的瓶颈. 可以用的方法: 1. 降低控制文件副本的数量,确保所有副本

与IO相关的等待事件troubleshooting-系列1

近来XX应用充分暴露出开发人员最初只关心功能,未考虑性能的问题,夜维.OLTP应用均出现了不同程度的与数据库相关的性能问题. 这个应用所在磁盘的IO较差,原因在于这块磁盘较旧,已进入更换的流程,但短期内还不能更换,对应用是个极大的隐患.而且也出现过某段时间IO非常差,导致应用处理速度非常缓慢.针对与IO相关的性能问题,MOS有篇文章(223117.1)介绍的就是与IO相关的troubleshooting,拜读一下. 这篇文章的目的:针对主要争用是IO相关的场景下,Oracle调优的一些思路. 主

与IO相关的等待事件troubleshooting-系列5

'db file scattered read'         这是另一种常见的等待事件.他产生于Oracle从磁盘读取多个块到Buffer Cache中非连续("scattered")缓存的时候.这种读一次最大值是DB_FILE_MULTIBLOCK_READ_COUNT.这种典型场景像全表扫描(Full Table Scans)和全索引快速扫描(Fast Full Index scans).         如果这个等待事件占据大部分等待时间,下面的方法可以用到: 1. 找到执行

【等待事件】等待事件系列(3+4)--System IO(控制文件)+日志类等待

 [等待事件]等待事件系列(3+4)--System IO(控制文件)+日志类等待   1  BLOG文档结构图     2  前言部分   2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 控制文件类等待 ② 日志类等待   2.2  相关参考文章链接 [推荐] 等待事件系列(1)--User I/O类型(下) http://blog.itpub.net/26736162/viewspace-2124435

【等待事件】等待事件系列(1)--User I/O类型

[等待事件]等待事件系列(1)--User I/O类型 1  BLOG文档结构图     2  前言部分   2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ①  等待事件系列(1)--User I/O类型     Tips: ① 本文在ITpub(http://blog.itpub.net/26736162).博客园(http://www.cnblogs.com/lhrbest)和微信公众号(xiaomaim

防患未然:Oracle gc等待事件的发现、处理与预防

系统环境 两节点的RAC:AIX6.1+Oracle 11.2.0.3.3   AWR里展示出来的各种症状(数据来自实例2) 虽然应用没有报障,但AWR报告里的各种迹象已经很明显了   (1)   gc buffer busy acquire排进了Top 5 Timed Foreground Events   图-1   (2)   除去DB CPU在gc buffer busy acquire之后的就是gc cr block busy了   图-2   (3)   2h21bq1mnc5kd这

【MOS】常见问题cursor library cache类型的等待事件

[MOS]常见问题:'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'类型的等待事件 (文档 ID 1525791.1) 文档内容 用途 问题和答案   什么是 'cursor: ' 等待事件?   最常见的等待事件是什么?   等待事件最常见的原因是什么?   如何避免这些等待事件?   可以在什么位置找到原因诊断以及关于这些等待事件的更多信息?   有用参考 参考 适用于: Oracle Database - Enterp

oracle等待事件7——事务上的等待事件

1.enq:TM-contention 执行DML期间,为防止对DML相关的对象进行修改,执行DML的进程必须对该表获得TM锁,若获得TM锁的过程发生争用,则等待enq:TM-contention事件. TM锁其用途十分明确,但是准确的概念及定义方面有容易混淆的一面.oracle的手册上关于锁的分类说明如下: DML锁:Date lock.执行DML时保护数据的锁.Row Lock(TX)保护特定行,Table Lock(TM)保护整个表,可以通过dba_kml_locks观察. DDL锁:Da