Oracle10g等待界面为还没有被ADDM 捕捉的即时性能问题提供了有价值的诊断数据。
“数据库太慢了！”
这句话通常出自一位严格的用户之口。假如您和我一样，那么在您的 DBA 生涯中您肯定无数次听到过这句话。
那么，您又怎样解决该问题呢？除了对用户置之不理之外（这是我们大多数人都不敢奢望的想法），您可能要做的第一件事就是查看是否有任何会话在等待数据库内部或外部的任何事件。
Oracle 提供了一个简单但一流的机制来达到此目的：V$SESSION_WAIT 视图。该视图显示了有助于您的诊断的各种信息，如一个会话正在等待或已经等待的事件，以及等待了多长时间和多少次。例如，假如会话在等待事件 "db file sequential read"，列 P1 和 P2 将显示会话正在等待的块的 file_id 和 block_id。
对于大多数等待事件而言，这个视图足够了，但它还不是一个强健的调整工具，之所以如此说，至少是因为以下两个重要原因：
该视图是当前情况的一个快照。当等待不再存在时，会话先前出现的那些等待的历史也将消失，从而使得事后诊断非常困难。V$SESSION_EVENT 提供了累积的但不是非常具体的数据。 V$SESSION_WAIT 包含了只与等待事件相关的信息；要获得所有其它的相关信息（如用户 ID 和终端），您必须将它和 V$SESSION 视图结合使用。
在 Oracle 数据库 10g 中，等待界面经过了彻底的重新设计，从而只需更少的 DBA 干预即可提供更多的信息。在本文中，我们将浏览这些新的特性，并了解它们如何帮助我们诊断性能问题。对于大多数性能问题，您可以从自动数据库诊断治理器 (ADDM) 中获得扩展分析，但对于还没有被 ADDM 捕捉的即时问题，等待界面将提供有价值的诊断数据。
增强的会话等待
第一个增强涉及到 V$SESSION_WAIT 本身。这一点通过示例可以很好地说明。
假定您的用户抱怨会话挂起了。您查明了该会话的 SID，并在 V$SESSION_WAIT 视图中选中了该 SID 的记录。输出显示如下。
SID: 269
SEQ# : 56
EVENT:enq:TX - row lock contention
P1TEXT :namemode
P1 : 1415053318
P1RAW: 54580006
P2TEXT :usn<<16 slot
P2 : 327681
P2RAW: 00050001
P3TEXT :sequence
P3 : 43
P3RAW:0000002B
WAIT_CLASS_ID: 4217450380
WAIT_CLASS#: 1
WAIT_CLASS : Application
WAIT_TIME: -2
SECONDS_IN_WAIT: 0
STATE:WAITED UNKNOWN TIME
注重左边显示的列；在这些列中，WAIT_CLASS_ID、WAIT_CLASS# 和 WAIT_CLASS 是 10g 中新增的列。列 WAIT_CLASS 指示等待的类型，必须将其作为有效的等待事件解决或者作为空闲的等待事件退出。在上面的例子中，等待类显示为 Application，这表示它是一个需要您注重的等待。
该列突出显示那些能够证实与您的调整最相关的少数几条记录。例如，您可以使用如下查询来获取事件的等待会话。
select wait_class, event, sid, state, wait_time, seconds_in_wait
from v$session_wait
order by wait_class, event, sid
/
下面是一个样例输出：
WAIT_CLASSEVENT SID STATEWAIT_TIME SECONDS_IN_WAIT
------------------------------ ---------- ------------------- ---------- ------
Application enq:TX - 269 WAITING 073
row lock contention
IdleQueue Monitor Wait270 WAITING 040
IdleSQL*Net message from client 265 WAITING073
Idlejobq slave wait 259 WAITING08485
Idlepmon timer280 WAITING073
Idlerdbms ipc message 267 WAITING0184770
Idlewakeup time manager 268 WAITING040
Network SQL*Net message to client 272 WAITED SHORT TIME -10
在这，您可以看到几个事件（如 Queue Monitor Wait 和 JobQueue Slave）被明确地归为 Idle 事件。您可以将它们作为非阻塞等待消除掉；不过，有时这些“空闲”事件可能指示一个内在的问题。例如，与 SQL*Net 相关的事件可能指示高网络延迟（除其他因素外）。
另一件要注重的重要的事情是，WAIT_TIME 的值为 -2。某些平台（如 Windows）不支持快速计时机制。假如在这些平台上没有设定初始化参数 TIMED_STATISTICS，那么将无法获得准确的计时统计数据。在这种情况下，在 Oracle9i 中，该列将显示一个非常大的数字，这使问题变得更加不清楚。在 10g 中，值 -2 指示这种情况 — 平台不支持快速定时机制并且没有设定 TIMED_STATISTICS。（对于本文剩下的部分，我们将假定存在一个快速计时机制。）
会话也显示等待
记得长期以来一直需要将 V$SESSION_WAIT 与 V$SESSION 结合使用以获得有关会话的其他具体信息吗？嗯，这已经成为历史了。在 10g 中，V$SESSION 视图还显示由 V$SESSION_WAIT 显示的等待。下面是 V$SESSION 视图其余的列，这些列显示了会话当前等待的等待事件。
EVENT# NUMBER
EVENTVARCHAR2(64)
P1TEXT VARCHAR2(64)
P1 NUMBER
P1RAWRAW(4)
P2TEXT VARCHAR2(64)
P2 NUMBER
P2RAWRAW(4)
P3TEXT VARCHAR2(64)
P3 NUMBER
P3RAWRAW(4)
WAIT_CLASS_IDNUMBER
WAIT_CLASS#NUMBER
WAIT_CLASS VARCHAR2(64)
WAIT_TIMENUMBER
SECONDS_IN_WAITNUMBER
STATEVARCHAR2(19)
这些列与 V$SESSION_WAIT 中的那些列相同，且显示相同的信息，从而不再需要在那个视图中查看它们了。因此，对于等待任意事件的任意会话，您仅需要查看一个视图。
让我们回到原来的问题：SID 为 269 的会话正等待事件 enq:TX — row lock contention，指示它正等待被另一个会话占用的锁。要诊断该问题，您必须识别占用锁的那个会话。但您如何才能做到这一点？
在 Oracle9i 及更低版本中，您可能得编写复杂（和极耗资源）的查询来获得占用锁的会话的 SID。而在 10g 中，您所要做的就是执行以下查询：
select BLOCKING_SESSION_STATUS, BLOCKING_SESSION
from v$session
where sid = 269
BLOCKING_SE BLOCKING_SESSION
----------- ----------------
VALID265
找到了：SID 为 265 的会话阻塞了会话 269。还能更轻易吗？
用户仍然在缠着您，因为用户的问题仍然没有得到满足的解答。为什么用户的会话花了这么长时间才完成？您可以执行以下命令来找出原因：
select * from v$session_wait_class where sid = 269;
输出返回为：
SID SERIAL# WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASSTOTAL_WAITS TIME_WAITED
---- ------- ------------- ----------- ------------- ----------- -----------
269110642174503801 Application873261537
269110632902558402 Configuration4 4
269110633864003675 Commit 1 0
269110627231689086 Idle 15148408
269110620001533157 Network15 0
269110617407597678 User I/O 26 1
注重这里有关会话等待的大量信息。现在您知道了，该会话已经为与应用程序相关的等待等待了 873 次（共 261,537 厘秒），在与网络相关的事件中等待了 15 次等等。
