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”节：
代码语言：javascript复制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”如下：
代码语言：javascript复制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”组件的百分比：
代码语言：javascript复制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报告：
代码语言：javascript复制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消耗。
(未完待续)
