与IO有关的等待事件troubleshooting-系列2
日期：2014-05-16 浏览次数：20494 次
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
&nbs
