当前位置导航:炫浪网>>网络学院>>编程开发>>Oracle教程

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
相关内容
赞助商链接