与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 % TotalEvent Waits Time (cs) Wt Time-------------------------------------------- ------------ ------------ -------direct path read 4,232 10,827 52.01db file scattered read 6,105 6,264 30.09direct path write 1,992 3,268 15.70control file parallel write 893 198 .95db 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消耗。
(未完待续)
