等待事件在10G中的加强
2009-11-27
我2篇关于等待事件的日志主要是翻译了国外的一篇文章，以作为我加强对10G等待事件学习/认识。
有兴趣的可以直接查看原文：
链接： http://www.dbspecialists.com/files/presentations/wait_events_10g.html

在平常的问题诊断和性能调优中，等待事件起到很重要的作用，是DBA的一个重要武器。
第一次引入了等待事件是在Oracle 7 ，到了9I，有超过400个等待事件。到了10G，等待事件的数量超过了800个。
下面是从9i， 10G中查看等待事件的数量：
SQL> select * from v$version where rownum < 2;

BANNER
----------------------------------------------------------------
Oracle9i Release 9.2.0.4.0 - Production
SQL> select count(*) from v$event_name;

COUNT(*)
----------
401

10G的等待事件数量：
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Nov 26 18:05:15 2009

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select count(*) from v$event_name;

COUNT(*)
----------
889
10G 中不单数量上有了惊人的跃升，而且有了很多细的优化。增加了几个动态试图，在已有的试图上增加了有帮助的字段。
优化一：等待事件名称更具备描述性
在10g以前，一些事件名称很含糊，需要在其他试图的协助下才找到真正的含义。举个例子，enqueue 表示行中的某行存在竞争，但至于是什么的竞争，单单查询v$session_wait是无法判断的。在10g中，latches, enqueues, and buffer busy waits 等待事件名称更具备描述性。
在10g，仍然有叫latch free的等待事件，但同时多了20多个与latch有关的事件，可以覆盖大多数常见与竞争有关的latch。
在10.2.0.4中有27个，不同的版本会有不同的差别。
SQL> select name from v$event_name where name like '%latch:%';
latch: cache buffers chains
latch: redo writing
latch: redo copy
latch: Undo Hint Latch
latch: In memory undo latch
latch: MQL Tracking Latch
latch: row cache objects
latch: shared pool
latch: library cache
latch: library cache lock
latch: library cache pin
latch: session allocation
latch: messages
latch: enqueue hash chains
latch: ges resource hash list
latch: gcs resource hash
latch: cache buffers lru chain
latch: checkpoint queue latch
latch: cache buffer handles
latch: object queue header operation
latch: object queue header heap
latch: redo allocation
latch: KCL gc element parent latch
latch: undo global data
latch: Change Notification Hash table latch
latch: virtual circuit queues
latch: parallel query alloc buffer

27 rows selected.

回想在10G前，如果我们遇到一个session在等待latch free的事件，那我们需要进行如下的查询以定位到底是那种竞争：
SQL> SELECT event, state, p1, p2, p3
2 FROM v$session_wait
3 WHERE sid = 162;

EVENT         STATE            P1      P2    P3
------------- ------- ----------- ------ -----
latch free    WAITING 15113593728      97     5
查询v$event_name，来判断P1,P2,P3所指的意思：
SQL> SELECT * FROM v$event_name WHERE name = 'latch free';
知道P2对应的是latch 号，可以通过v$latch 试图来查看是什么latch。
EVENT# NAME       PARAMETER1      PARAMETER2      PARAMETER3
------ ---------- --------------- --------------- ---------------
     3 latch free address         number          tries
SQL> SELECT name
2 FROM   v$latch
3 WHERE latch# = 97;

NAME
--------------------
cache buffers chains
到了10g，一切都变的简单，只需要一个sql就可以：
SQL> SELECT event, state
2 FROM v$session_wait
3 WHERE sid = 162;

EVENT STATE
------------------------------ -------
latch: cache buffers chains WAITING
具备描述性的事件名称可以减少2步就可以获知导致session在等待latch。更加详细的事件名称可以帮助DBA快速的定位等待的根源。

对于enqueue，oracle 10g同样也做了详细的描述，让其具备更好的描述。不再存在enqueue 这样的等待事件，取而代之的是200多个更加详细的等待事件。
在过去，如果遇到sessoin在等待enqueue，那需要做对P1参数做编码才判断出来lock的类型。
SQL> SELECT event, state, seconds_in_wait siw
2 FROM v$session_wait
3 WHERE sid = 96;

EVENT STATE SIW
----------------------------------- ------------------- ----------
enqueue WAITING 24

SQL> SELECT sid,
2         CHR (BITAND (p1,-16777216) / 16777215) ||
3         CHR (BITAND (p1, 16711680) / 65535) enq,
4         DECODE (CHR (BITAND (p1,-16777216) / 16777215) ||
5                 CHR (BITAND (p1, 16711680) / 65535),
6                   'TX', 'Transaction (RBS)',
7                   'TM', 'DML Transaction',
8                   'TS', 'Tablespace and Temp Seg',
9                   'TT', 'Temporary Table',
10                   'ST', 'Space Mgt (e.g., uet$, fet$)',
11                   'UL', 'User Defined',
12                   CHR (BITAND (p1,-16777216) / 16777215) ||
13                   CHR (BITAND (p1, 16711680) / 65535)) enqueue_name,
14         DECODE (BITAND (p1, 65535), 1, 'Null', 2, 'Sub-Share',
15                   3, 'Sub-Exclusive', 4, 'Share', 5, 'Share/Sub-Exclusive',
16                   6, 'Exclusive', 'Other') lock_mode
17 FROM   v$session_wait
18 WHERE sid = 96;

SID ENQ ENQUEUE_NAME LOCK_MODE
----- ---- ------------------------------ ----------
96 TX Transaction (RBS) Exclusive

在10g，我们可以从enqueue中直接获取锁的类型：
SQL> SELECT event, state, seconds_in_wait siw
2 FROM v$session_wait
3 WHERE sid = 143;

EVENT STATE SIW
----------------------------------- ------------------- ----------
enq: TX - row lock contention WAITING 495
对于 buffer busy waits，在一种情况是一个session在等待另外一个session把数据从disk中读到buffer pool的等待，事件名称改为：read by other session。
除了以上列举的外，Oracle 10g 对其他的等待事件也做了明细说明。很难有一篇文章来概括全部。
在10G,Oracle把等待事件做了分类，帮助BDA更加容易的定位问题。
在10.2.0.4版本中，等待事件的分类：
SQL> select distinct WAIT_CLASS from v$event_name;

WAIT_CLASS
----------------------------------------------------------------
User I/O
Application
Network
Concurrency
Administrative
Configuration
Scheduler
Cluster
Other
Idle
System I/O
Commit

12 rows selected.
SQL> select count(*) , count(*)/889*100 , wait_class from v$event_name group by WAIT_CLASS order by 1;

COUNT(*) COUNT(*)/889*100 WAIT_CLASS
---------- ---------------- ----------------------------------------------------------------
         1       .112485939 Commit
         2       .224971879 Scheduler
        12       1.34983127 Application
        17       1.91226097 User I/O
        23        2.5871766 Configuration
        24       2.69966254 System I/O
        25       2.81214848 Concurrency
        27       3.03712036 Network
        46       5.17435321 Administrative
        48       5.39932508 Cluster
        63       7.08661417 Idle
       601       67.6040495 Other

把等待事件分类的好处在于哪呢？还是拿事实说话。
SQL> SELECT   wait_class, name
2 FROM     v$event_name
WHERE    name LIKE 'enq%'
AND      wait_class <> 'Other'
ORDER BY wait_class; 3    4    5

WAIT_CLASS                                                       NAME
---------------------------------------------------------------- ----------------------------------------------------------------
Administrative                                                   enq: ZG - contention
Administrative                                                   enq: TW - contention
Administrative                                                   enq: DB - contention
Application                                                      enq: KO - fast object checkpoint
Application                                                      enq: TM - contention
Application                                                      enq: TX - row lock contention
Application                                                      enq: RO - fast object reuse
Application                                                      enq: UL - contention
Application                                                      enq: PW - flush prewarm buffers
Application                                                      enq: RO - contention
Concurrency                                                      enq: TX - index contention
Configuration                                                    enq: SS - contention
Configuration                                                    enq: SQ - contention
Configuration                                                    enq: HW - contention
Configuration                                                    enq: ST - contention
Configuration                                                    enq: TX - allocate ITL entry
如enq: TX - row lock contention 和enq: TM - contention 归并到Application 的类别中，那DBA可以很容易的判断到这些等待事件的发生是由于应用行为导致的。
再如 enq: HW - contention（高水位标志扩展），enq: ST - contention （空间管理）归并到Configuration 类别，那可以通过更改在对象和数据库中的设置来缓解。
有时空闲的等待事件是导致问题的根源，所以不能在一股脑的忽略这些空闲事件。

-TO Continue-

ITPub博客

等待事件在10G中的加强

最新文章