Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（十一）

10 g 等待界面为还没有被 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 数据库 10 g 中，等待界面经过了彻底的重新设计，从而只需更少的 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 是 10 g 中新增的列。列 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 ，那么将无法获得准确的计时统计数据。在这种情况下，在 Oracle9 i 中，该列将显示一个非常大的数字，这使问题变得更加不清晰。在 10 g 中，值 -2 指示这种情况 — 平台不支持快速定时机制并且没有设定 TIMED_STATISTICS 。（对于本文剩下的部分，我们将假定存在一个快速计时机制。）

会话也显示等待

记得长期以来一直需要将 V$SESSION_WAIT 与 V$SESSION 结合使用以获得有关会话的其他详细信息吗？嗯，这已经成为历史了。在 10 g 中， 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 ，指示它正等待被另一个会话占用的锁。要诊断该问题，您必须识别占用锁的那个会话。但您如何才能做到这一点？

在 Oracle9 i 及更低版本中，您可能得编写复杂（和极耗资源）的查询来获得占用锁的会话的 SID 。而在 10 g 中，您所要做的就是执行以下查询：

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

3386400367 　　　　　　　5 Commit 　　　　　　　　2625 　　　　 1925

2723168908 　　　　　　　6 Idle 　　　　　　　　645527 　　219397953

2000153315 　　　　　　　7 Network 　　　　　　　　2125 　　　　　　2

1740759767 　　　　　　　8 User I/O 　　　　　　　 5085 　　　　 3006

4108307767 　　　　　　　9 System I/O 　　　　　 127979 　　　　18623

大多数问题不是孤立出现的；它们留下了揭示真相的线索，模式可以识别这些线索。可以按如下方式从等待类的一个历史视图中查看模式。

select * from v$waitclassmetric;

这个视图存储了最后一分钟内与等待类相关的统计数据。

select wait_class#, wait_class_id,

average_waiter_count "awc", dbtime_in_wait,

time_waited, wait_count

from v$waitclassmetric

/

WAIT_CLASS# WAIT_CLASS_ID AWC DBTIME_IN_WAIT TIME_WAITED WAIT_COUNT

----------- ------------- ---- -------------- ----------- ----------

　　　　　0 　　1893977003 　　0 　　　　　　　0 　　　　　0 　　　　　1

　　　　　1 　　4217450380 　　2 　　　　　　 90 　　　 1499 　　　　　5

　　　　　2 　　3290255840 　　0 　　　　　　　0 　　　　　4 　　　　　 3

　　　　　3 　　4166625743 　　0 　　　　　　　0 　　　　　0 　　　　　 0

　　　　　4 　　3875070507 　　0 　　　　　　　0 　　　　　0 　　　　　 1

　　　　　5 　　3386400367 　　0 　　　　　　　0 　　　　　0 　　　　　 0

　　　　　6 　　2723168908 　 59 　　　　　　　0 　　 351541 　　　　 264

　　　　　7 　　2000153315 　　0 　　　　　　　0 　　　　　 0 　　　　　25

　　　　　8 　　1740759767 　　0 　　　　　　　0 　　　　　 0 　　　　　 0

　　　　　9 　　4108307767 　　0 　　　　　　　0 　　　　　 8 　　　　 100

　　　　 10 　　2396326234 　　0 　　　　　　　0 　　　　　 0 　　　　　　0

　　　　 11 　　3871361733 　　0 　　　　　　　0 　　　　　 0 　　　　　　0

注意 WAIT_CLASS_ID 和相关的统计数据。对于值 4217450380 ，我们看到 2 个会话在最后一分钟内总共等待了该类 5 次（ 1,499 厘秒）。但该等待类是什么？您可以从 V$SYSTEM_WAIT_CLASS 中获取这一信息（如上所示） — 就是 Application 类。

注意名称为 DBTIME_IN_WAIT 的列，这是一个非常有用的列。在我们 第 6 周 关于自动工作负载信息库 (AWR) 的部分中，您可能还记得在 10 g 中是以更细粒化的方式来报告时间的，并且可以确定在数据库中花费的准确时间。 DBTIME_IN_WAIT 显示在数据库中花费的时间。

一切都留有线索

用户终于离开了，您长舒了一口气。但您可能仍然想寻根究底，希望查明主要是哪些等待造成用户会话中的问题。当然，您可以通过查询 V$SESSION_WAIT 而轻易地得到答案 — 但不幸的是，等待事件现在不存在了，因此该视图没有它们的任何记录。您该怎么办？

在 10 g 中，自动保留活动会话最后 10 个事件的会话等待历史。这个历史可通过 V$SESSION_WAIT_HISTORY 视图查看。要找出这些事件，您可以简单地执行：

select event, wait_time, wait_count

from v$session_wait_history

where sid = 265

/

EVENT 　　　　　　　　　　　　　　WAIT_TIME WAIT_COUNT

------------------------------ ---------- ----------

log file switch completion 　　　　　2 　　　 　1

log file switch completion 　　　　　1　　　 　 1

log file switch completion 　　　　　0　　　 　 1

SQL*Net message from client 　　49852 　　　 　 1

SQL*Net message to client 　　　　　0 　　　 　　1

enq:TX - row lock contention 　　　28 　　　　　1

SQL*Net message from client 　　　131 　　　 　1

SQL*Net message to client 　　　　　0 　　　　　1

log file sync 　　　　　　　　　　　2 　　　　 　1

log buffer space 　　　　　　　　　　1 　　　　　1

当会话变为非活动状态或断开时，记录从该视图中消失。不过，这些等待的历史保留在 AWR 表中，以便进一步分析。从 AWR 中显示会话等待的视图是 V$ACTIVE_SESSION_HISTORY 。（同样，有关 AWR 的更多信息，请参考本系列的 第 6 周 。）

结论

通过 Oracle 数据库 10 g 中的等待模型的增强，分析性能问题变得非常容易。提供的会话等待历史可以帮助您在会话经历等待后诊断问题。将等待归为各种等待类还有助于您了解每种类型等待所造成的影响，这在研究正确的纠正方法时将带来便利。

有关等待事件动态性能视图和等待事件本身的更多信息，请参考《 Oracle 数据库性能调整指南 10g 第 1 版 (10.1) 》的 第 10 章 。