等待事件在10G中的加強

等待事件在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部落格 ” ，連結：http://blog.itpub.net/40239/viewspace-620888/，如需轉載，請註明出處，否則將追究法律責任。

等待事件在10G中的加強

相關文章