前言
在处理被ADDM捕捉的突发的性能问题中，10g等待接口提供非常有价值的数据用于诊断。作为一个DBA，你可能遇到过很多次用户抱怨“数据库非常慢了”。那么你是如何定位这种问题的呢？你第一步要做的肯定是查看是否有会话在等待数据库内部或外部的什么资源。
Oracle提供了一个简单但是又很有效的机制来获取这些信息：视图V$SESSION_WAIT。这一视图提供了各种信息以帮助诊断如一个会话正在等待和已经等待的事件、及等待了多少、等待时间多长。例如，如果会话正在等待事件“db file sequential read”，字段P1和P2就标识会话正在等待的数据块的file_id和block_id。
对于大多数等待事件来说，这个视图已经足够了。但由于以下两个原因，它很难成为一个强有力的优化工具：
· 这个视图只是当前状态的一个快照。当等待不存在了，会话早前关于这些等待的历史信息也没有了，使事后诊断分析变得很困难。
V$SESSION_EVENT视图提供了累积的但不够详细的数据。
· V$SESSION_WAIT视图仅包含了等待事件的信息。要获取其他相关信息如USERID和终端信息就必须和视图V$SESSION连接查询。
在Oracle 10g中，等待接口从根本上被重新设计了，提供了更多的信息，而且减少了DBA的干预。在这篇文章中，我们将探索这些特性，看看它们如何帮助我们来诊断性能问题。对于大多数性能问题，你能从ADDM中得到扩展的分析信息，但是ADDM没有捕捉到哪些即时问题的信息。而等待接口提供了非常有用的数据用于诊断。
增强的会话等待
首先一个增强就是对视图V$ESSION_WAIT本身的。这可以从一个例子来解释。加入您的用户抱怨会话被hang住了。你查出这个会话的SID，并从视图V$SESSION_WAIT中找出这个SID的记录。以下就是输出内容：
请注意哪些黑体字段。在这些字段中，WAIT_CLASS_ID、WAIT_CLASS#和WAIT_CLASS字段是10g中新增的。字段WAIT_CLASS表示这个等待的类型是一个有效的等待事件还是一个可以被忽略的空闲等待事件。在上面的例子中，等待类型是”Application”，表明它在等待你的干预。SID : 269 SEQ# : 56 EVENT : enq: TX - row lock contention P1TEXT : name|mode 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
这一字段让你更加明确哪些字段可以用于调优。例如，你可以用以下查询来获取等待这个事件的会话：
在这你可以看到几个事件（如Queue Monitor Wait和JobQueue Slave）被明确标注为Idle事件。你可以把它们视为非阻塞等待忽略掉。但是，有时候这些”idle”事件预示着一个内部问题。例如，与SQL*NET相关的事件可能预示网络可能出现潜在问题。SQL> select wait_class, event, sid, state, wait_time, seconds_in_wait 2 from v$session_wait 3 order by wait_class, event, sid 4 / WAIT_CLASS EVENT SID STATE WAIT_TIME SECONDS_IN_WAIT ---------- -------------------- ---------- ------------------- ---------- --------------- Application enq: TX - 269 WAITING 0 73 row lock contention Idle Queue Monitor Wait 270 WAITING 0 40 Idle SQL*Net message from client 265 WAITING 0 73 Idle jobq slave wait 259 WAITING 0 8485 Idle pmon timer 280 WAITING 0 73 Idle rdbms ipc message 267 WAITING 0 184770 Idle wakeup time manager 268 WAITING 0 40 Network SQL*Net message to client 272 WAITED SHORT TIME -1 0
另外一个需要注意的重要信息就是字段WAIT_TIME的值是－2。一些平台，如Windows，不支持快速计时机制。如果在哪些平台上，初始化参数TIMED_STATISTICS没有设置为on，就无法检测到精确的计时统计。在那样的情况下，在Oracle9i中，这个字段的值是一个非常大的值，它会让以后的问题定位产生混乱。在10g中，值－2就表示是这种情况——平台不支持快速计时机制并且TIME_STATISTICS被设置为off。
