大多数问题的发生都不是孤立的。在它们背后还存在一些其他问题，这些问题可以通过一种样式来定位。这一样式可以通过以下查询语句来查询一个历史视图来获得：SQL> 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
请注意字段WAIT_CLASS_ID和他的统计数据。对于值4217450380，我们发现有2个会话在等待这一类型的事件共5次、1499厘秒。但是这一类型等待是什么等待事件呢？你可以从视图V$SYSTEM_WAIT_CLASS中得到这个信息。如上所示，这是Application类型事件。SQL> select wait_class#, wait_class_id, 2 average_waiter_count "awc", dbtime_in_wait, 3 time_waited, wait_count 4 from v$waitclassmetric 5 / 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
再注意DBTIME_IN_WAIT这一非常有用的字段。你也许还记得在10g的AWR中会在很细的粒度下记录下数据库的消耗时间。DBTIME_IN_WAIT就表示数据库消耗的等待时间。
