Oracle 10G 最佳20位新特性：等待界面

　　10g 等待界面为还没有被 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　　　　　　　　　 :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
　　注意以黑体显示的列；在这些列中，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_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
　　在这，您可以看到几个事件（如 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
　　EVENT　　　　　　　　　　　VARCHAR2(64)
　　P1TEXT　　　　　　　　　　 VARCHAR2(64)
　　P1　　　　　　　　　　　　 NUMBER
　　P1RAW　　　　　　　　　　　RAW(4)
　　P2TEXT　　　　　　　　　　 VARCHAR2(64)
　　P2　　　　　　　　　　　　 NUMBER
　　P2RAW　　　　　　　　　　　RAW(4)
　　P3TEXT　　　　　　　　　　 VARCHAR2(64)
　　P3　　　　　　　　　　　　 NUMBER
　　P3RAW　　　　　　　　　　　RAW(4)
　　WAIT_CLASS_ID　　　　　　　NUMBER
　　WAIT_CLASS#　　　　　　　　NUMBER
　　WAIT_CLASS　　　　　　　　 VARCHAR2(64)
　　WAIT_TIME　　　　　　　　　NUMBER
　　SECONDS_IN_WAIT　　　　　　NUMBER
　　STATE　　　　　　　　　　　VARCHAR2(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
　　----------- ----------------
　　VALID　　　　　　　　　　265
　　
　　找到了：SID 为 265 的会话阻塞了会话 269。还能更容易吗？
　　
　　有多少等待？
　　用户仍然在缠着您，因为用户的问题仍然没有得到满意的解答。为什么用户的会话花了这么长时间才完成？您可以执行以下命令来找出原因：
　　
　　select * from v$session_wait_class where sid = 269;
　　
　　输出返回为：
　　
　　SID SERIAL# WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS　　TOTAL_WAITS TIME_WAITED
　　---- ------- ------------- ----------- ------------- ----------- -----------
　　269　　1106　　4217450380　　1 Application　　　873　　　261537
　　269　　1106　　3290255840　　2 Configuration　　4　　　　　 4
　　269　　1106　　3386400367　　5 Commit　　　　　 1　　　　　 0
　　269　　1106　　2723168908　　6 Idle　　　　　　 15　　　148408
　　269　　1106　　2000153315　　7 Network　　　　　15　　　　　 0
　　269　　1106　　1740759767　　8 User I/O　　　　 26　　　　　 1
　　注意这里有关会话等待的大量信息。现在您知道了，该会话已经为与应用程序相关的等待等待了 873 次（共 261,537 厘秒），在与网络相关的事件中等待了 15 次等等。
　　
　　以此类推，您可以使用以下查询来查看系统范围的等待类的统计数据。同样，时间是以厘秒为单位的。
　　
　　select * from v$system_wait_class;
　　
　　WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS　　TOTAL_WAITS TIME_WAITED
　　------------- ----------- ------------- ----------- -----------
　　1893977003　　　0 Other　　　　　　　　2483　　　 18108
　　4217450380　　　1 Application　　　　　1352　　　386101
　　3290255840　　　2 Configuration　　　　　82　　　　 230
　　3875070507　　　4 Concurrency　　　　　　80　　　　 395
　　33864003

查看本文来源