Oracle-監控oracle的等待事件

Michael_DD發表於2014-12-02
Oracle-監控oracle的等待事件


select event,
       sum(decode(wait_Time, 0, 0, 1)) "Prev",
       sum(decode(wait_Time, 0, 1, 0)) "Curr",
       count(*) "Tot"
  from v$session_Wait
 group by event
 order by 4;

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 等待事件概述
Oracle的等待事件是衡量oracle執行狀況的重要依據及指標.
等待事件的概念是在Oracle7.0.1.2中引入的,大致有100個等待事件。在Oracle 8.0中這個數目增加到了大約150個,在Oracle8i中大約有200個事件,在Oracle9i中大約有360個等待事件。
主要有兩種類別的等待事件,即空閒(idle)等待事件和非空閒(non-idle)等待事件。
空閒等待事件是指Oracle正等待某種工作,比如用sqlplus登入之後,但沒有進一步發出任何命令,此時該session就處於SQL*Net message from/to client等待事件狀態,等待使用者發出命令,任何的在診斷和最佳化資料庫的時候,我們不用過多注意這部分事件。非空閒等待事件專門針對Oracle的活動,指資料庫任務或應用執行過程中發生的等待,這些等待事件是我們在調整資料庫的時候應該關注與研究的。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2  oracle等待事件型別
每一個等待事件都屬於某一類, 下面給出了每一類等待事件的描述.
管理類: administrative
類等待事件是由於DBA的管理命令引起的,這些命令要求使用者處於等待狀態,比如,重建索引。
應用程式類:
此類等待事件是由於使用者應用程式的程式碼引起的(比如:鎖等待).
群集類:Cluster
此類等待事件和真正應用群集RAC的資源有關。(比如:gc cr block busy等待事件).
提交確認類:Commit
此類等待事件只包含一種等待事件--在執行了一個commit命令後,等待一個重做日誌寫確認(也就是log file sync).
併發類:Concurrency
此類等待事件是由內部資料庫資源引起的,比如閂鎖。
配置類:Configuration
此類等待事件是由資料庫或例項的不當配置造成的,比如,重做日誌檔案尺寸太小,共享池的大小等。
空閒類:Idle
此類等待事件意味著會話不活躍,等待工作。比如,sql * net messages from client。
網路類:Network
和網路環境相關的一些等待事件,比如sql* net more data to dblink。
Other
此類等待事件通常比較少見。
排程類:Scheduler
Resource Manager related waits (for example, 'resmgr: become active')
系統I/O類:System I/O
此類等待事件透過是由後臺程式的I/O操作引起的,比如DBWR等待,db file paralle write。
使用者I/O類:User I/O
此類等待事件通常是由使用者I/O操作引起的,比如db file sequential read。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 等待事件詳細描述
1, db file scattered read (DB檔案分散讀取)
這種情況通常與全表掃描相關. 當資料庫進行全表掃描時, 基於效能的考慮, 資料會分散(scattered)讀入buffer cache. 如果這個等待事件比較顯著, 可能考慮檢視對應的表有沒有建立合適的索引.
然而這個等待事件並不一定就意味著效能低下, 在某些條件下oracle會主動使用全表掃描來替換索引掃描以提高效能, 這和訪問的資料量有關, 在CBO下oracle會進行更為智慧的選擇, RBO下oracle更傾向於使用索引.
因為全表掃描到記憶體的資料塊被置於LRU連結串列的冷端, 所以這些資料塊將可能在較短時間內被置換出實體記憶體, 為了避免反覆物理IO, 對頻繁訪問的較小的資料表,可以選擇把他們cache到記憶體中.
當這個等待時間比較顯著時, 可以結合v$session_longops動態效能檢視來進行診斷, 該檢視中記錄了長時間(執行時間超過6秒)執行的事務, 可能很多是全表掃描操作.
Column    Datatype    Description
SID    NUMBER    Session identifier
SERIAL#    NUMBER    Session serial number
OPNAME    VARCHAR2(64)    Brief description of the operation
TARGET    VARCHAR2(64)    The object on which the operation is carried out
TARGET_DESC    VARCHAR2(32)    Description of the target
SOFAR    NUMBER    The units of work done so far
TOTALWORK    NUMBER    The total units of work
UNITS    VARCHAR2(32)    The units of measurement
START_TIME    DATE    The starting time of operation
LAST_UPDATE_TIME    DATE    Time when statistics last updated
TIME_REMAINING    NUMBER    Estimate (in seconds) of time remaining for the operation to complete
ELAPSED_SECONDS    NUMBER    The number of elapsed seconds from the start of operations
CONTEXT    NUMBER    Context
MESSAGE    VARCHAR2(512)    Statistics summary message
USERNAME    VARCHAR2(30)    User ID of the user performing the operation
SQL_ADDRESS    RAW(4)    Used with the value of the SQL_HASH_VALUE column to identify the SQL statement associated with the operation
SQL_HASH_VALUE    NUMER    Used with the value of the SQL_ADDRESS column to identify the SQL statement associated with the operation
QCSID    NUMBER    Session identifier of the parallel coordinator


2, db file sequential read(DB 檔案順序讀取)
這一事件通常顯示與單個資料塊相關的讀取操作, 比如對索引塊的讀取. 如果這個等待事件比較顯著, 可能表示在多表連線中, 表的連結順序存在問題, 可能沒有正確的使用驅動表; 或者可能說明不加選擇地進行索引.


3, free buffer (釋放緩衝區)
這個等待事件表明系統正在等待記憶體中的可用空間,這說明當前Buffer 中已經沒有Free 的記憶體空間。Free Buffer 等待可能說明DBWR 的寫出速度不夠,或者磁碟存在嚴重的競爭,可以需要考慮增加檢查點、使用更多的DBWR 程式,或者增加物理磁碟的數量,分散負載,平衡IO。


4, buffer busy(緩衝區忙)
該等待事件表示正在等待一個以unshareable方式使用的緩衝區,或者表示當前正在被讀入buffer cache。一般來說Buffer Busy Wait不應大於1%。檢查緩衝等待統計部分(或V$WAITSTAT),看一下等待是否位於段頭(Segment Header)。如果是,可以考慮增加自由列表(freelist,對於Oracle8i DMT)或者增加freelist groups(在很多時候這個調整是立竿見影的,在8.1.6之前,這個freelists引數不能動態修改;在8.1.6及以後版本,動態修改 feelists需要設定COMPATIBLE至少為8.1.6).
This view lists block contention statistics. This table is only updated when timed statistics are enabled.
Column    Datatype    Description
CLASS    VARCHAR2(18)    Class of the block
COUNT    NUMBER    Number of waits by this OPERATION for this CLASS of block
TIME    NUMBER    Sum of all wait times for all the waits by this OPERATION for this CLASS of block
select * from V$WAITSTAT
CLASS    COUNT    TIME
data block    318671    91287
undo header    50352    1172
undo block    28    1
segment header    10    5
file header block    8    1
1st level bmb    3    0
bitmap index block    0    0
system undo block    0    0
system undo header    0    0
unused    0    0
bitmap block    0    0
save undo header    0    0
save undo block    0    0
sort block    0    0
free list    0    0
3rd level bmb    0    0
2nd level bmb    0    0
extent map    0    0

如果這一等待位於undo header,可以透過增加回滾段(rollback segment)來解決緩衝區的問題。如果等待位於undo block上,我們可能需要檢查相關應用,適當減少大規模的一致性讀取,或者降低一致性讀取(consistent read)的表中的資料密度或者增大DB_CACHE_SIZE。
如果等待處於data block,可以考慮將頻繁併發訪問的表或資料移到另一資料塊或者進行更大範圍的分佈(可以增加pctfree值,擴大資料分佈,減少競爭),以避開這個"熱點"資料塊,或者可以考慮增加表中的自由列表或使用本地化管理的表空間(Locally Managed Tablespaces)。
如果等待處於索引塊,應該考慮重建索引、分割索引或使用反向鍵索引。為了防止與資料塊相關的緩衝忙等待,也可以使用較小的塊:在這種情況下,單個塊中的記錄就較少,所以這個塊就不是那麼"繁忙";或者可以設定更大的pctfree,使資料擴大物理分佈,減少記錄間的熱點競爭。
在執行DML (insert/update/ delete)時,Oracle向資料塊中寫入資訊,對於多事務併發訪問的資料表,關於ITL的競爭和等待可能出現,為了減少這個等待,可以增加 initrans,使用多個ITL槽。在Oracle9i 中,引入了一個新概念:ASSM(Segment Space Management Auto)。透過這個新特性Oracle 使用點陣圖來管理空間使用。
ASSM 結合LMT 徹底改變了Oracle 的儲存機制,點陣圖freelist 能夠減輕緩衝區忙等待(buffer busy wait),這個問題在Oracle9i 以前的版本里曾是一個嚴重的問題。
Oracle 宣稱ASSM 顯著地提高了DML 併發操作的效能,因為(同一個)點陣圖的不同部分可以被同時使用,這樣就消除了尋找剩餘空間的序列化。根據Oracle 的測試結果,使用點陣圖freelist 會消除所有分段頭部(對資源)的爭奪,還能獲得超快的併發插入操作。在Oracle9i 之中,Buffer Busy wait 不再常見!


5, latch free (latch 釋放)
latch是一種低階排隊機制,用於保護SGA中共享記憶體結構。latch就像是一種快速地被獲取和釋放的記憶體鎖。用於防止共享記憶體結構被多個使用者同時訪問。如果latch不可用,就會記錄latch釋放失敗(latch free miss )。有兩種與閂有關的型別:
■ 立刻。
■ 可以等待。
假如一個程式試圖在立刻模式下獲得閂,而該閂已經被另外一個程式所持有,如果該閂不能立可用的話,那麼該程式就不會為獲得該閂而等待。它將繼續執行另一個操作。
大多數latch問題都與以下操作相關:
沒有很好的是用繫結變數(library cache latch)、重作生成問題(redo allocation latch)、緩衝儲存競爭問題(cache buffers LRU chain),以及buffer cache中的存在"熱點"塊(cache buffers chain)。
通常我們說,如果想設計一個失敗的系統,不考慮繫結變數,這一個條件就夠了,對於異構性強的系統,不使用繫結變數的後果是極其嚴重的。
另外也有一些latch等待與bug有關,應當關注Metalink相關bug的公佈及補丁的釋出。當latch miss ratios大於0.5%時,就應當研究這一問題。

6, log buffer space(日誌緩衝空間)
當你將日誌緩衝(log buffer)產生重做日誌的速度比LGWR 的寫出速度快,或者是當日志切換(log switch)太慢時,就會發生這種等待。這個等待出現時,通常表明redo log buffer 過小,為解決這個問題,可以考慮增大日誌檔案的大小,或者增加日誌緩衝器的大小。
另外一個可能的原因是磁碟I/O 存在瓶頸,可以考慮使用寫入速度更快的磁碟。在允許的條件下設定可以考慮使用裸裝置來存放日誌檔案,提高寫入效率。在一般的系統中,最低的標準是,不要把日誌檔案和資料檔案存放在一起,因為通常日誌檔案只寫不讀,分離存放可以獲得效能提升。



+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 等待事件相關檢視
1, v$session_wait
這是一個尋找效能瓶頸的關鍵檢視, 它提供任何情況下session在資料庫中當前正在等待什麼(如果session當前什麼也沒在做, 則顯示它最後等待的事件)
每一個連結到例項的session都對應一條記錄.
Column    Datatype    Description
SID    NUMBER    Session identifier
SEQ#    NUMBER    Sequence number that uniquely identifies this wait. Incremented for each wait.
EVENT    VARCHAR2(64)    Resource or event for which the session is waiting session當前正在等待的事件, 或者最後一次等待事件.
P1TEXT    VARCHAR2(64)    Description of first additional parameter
P1    NUMBER    First additional parameter
P1RAW    RAW(4)    First additional parameter
P2TEXT    VARCHAR2(64)    Description of second parameter
P2    NUMBER    Second additional parameter
P2RAW    RAW(4)    Second additional parameter
P3TEXT    VARCHAR2(64)    Description of third parameter
P3    NUMBER    Third additional parameter
P3RAW    RAW(4)    Third additional parameter
WAIT_TIME    NUMBER    A nonzero value is the session's last wait time. A zero value means the session is currently waiting.
SECONDS_IN_WAIT    NUMBER    If WAIT_TIME = 0, then SECONDS_IN_WAIT is the seconds spent in the current wait condition. If WAIT_TIME > 0, then SECONDS_IN_WAIT is the seconds since the start of the last wait, and SECONDS_IN_WAIT - WAIT_TIME / 100 is the active seconds since the last wait ended.
STATE    VARCHAR2(19)    Wait state:
?    0 - WAITING (the session is currently waiting)
?    -2 - WAITED UNKNOWN TIME (duration of last wait is unknown)
?    -1 - WAITED SHORT TIME (last wait <1/100th of a second)
?    >0 - WAITED KNOWN TIME (WAIT_TIME = duration of last wait)

2, v$session_event
本檢視記錄了每個session的每一項等待事件. 由上文所知v$session_wait顯示了session的當前等待事件, 而v$sesion_event則記錄了session自啟動起所有的事件.
Column    Datatype    Description
SID    NUMBER    The ID of the session
EVENT    VARCHAR2(64)    The name of the wait event
See Also: Appendix A, "Oracle Wait Events"
TOTAL_WAITS    NUMBER    The total number of waits for this event by this session
TOTAL_TIMEOUTS    NUMBER    The total number of timeouts for this event by this session
TIME_WAITED    NUMBER    The total amount of time waited for this event by this session, in hundredths of a second
AVERAGE_WAIT    NUMBER    The average amount of time waited for this event by this session, in hundredths of a second
MAX_WAIT    NUMBER    The maximum time (in hundredths of a second) waited for this event by this session

3, 查詢所有連線的例項的session的相關資訊

-- session總體等待
select a.SID,a.USERNAME,a.machine,a.TERMINAL,b.EVENT,
b.time_wait,b.max_wait,b.TOTAL_WAITS,b.TOTAL_TIMEOUTS
from v$session a,
     V$SESSION_EVENT b
where a.SID = b.SID
  and a.status = 'ACTIVE'
  and user# >0;

-- session當前等待
select a.SID,a.USERNAME,a.machine,a.TERMINAL,b.EVENT,b.WAIT_TIME,b.SECONDS_IN_WAIT,b.STATE
from v$session a,
     V$SESSION_wait b
where a.SID = b.SID
  and a.status = 'ACTIVE'
  and user# >0;

-- 當前session正在執行語句
select a.SID,a.USERNAME,a.machine,a.TERMINAL,b.PIECE,b.SQL_TEXT
from v$session a,
     v$sqltext b
where b.ADDRESS = decode(a.SQL_HASH_VALUE,0,a.PREV_SQL_ADDR,a.SQL_ADDRESS)
  and a.status = 'ACTIVE'
  and user# >0
order by a.SQL_ADDRESS,b.PIECE;

-- session當前等待
select a.SID,a.USERNAME,a.machine,a.TERMINAL,c.NAME,b.VALUE
from v$session a,
     V$SESStat b,
     v$statname c
where a.SID = b.SID
  and b.STATISTIC# = c.STATISTIC#
  and a.status = 'ACTIVE'
  and user# >0
  and b.value > 0;

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29500582/viewspace-1353786/,如需轉載,請註明出處,否則將追究法律責任。

相關文章