Oracle Wait Interface解釋

Oracle Wait Interface

       Oracle等待事件的種類包括：I/O, locks, latches, enqueues, background process activities, network latencies, memory,等。可以透過V$SYSTEM_WAIT_CLASS查詢到。

       使用之前必須設定TIMED_STATISTICS=TRUE。

 

OWI的關鍵元件

檢視

·V$EVENT_NAME：包含定義的所有等待事件；

·V$SESSION_WAIT：顯示每個會話當前正在等待的時間和資源的詳細資訊，這是一個實時檢視；

在10G中，v$session_wait已經合併到了v$session 檢視中，雖然仍包含v$session_wait。

·V$SESSION_EVENT：顯示當前連線的會話的等待事件的聚集；

·V$SYSTEM_EVENT：顯示所有會話遇到的所有等待事件的聚集；

       Oracle 10G新增的關鍵元件包括：

•          V$SESTEM_WAIT_CLASS

•          V$SESSION_WAIT_CLASS

•          V$SESSION_WAIT_HISTORY

•          V$EVENT_HISTOGRAM

•          V$ACTIVE_SESSION_HISTORY

跟蹤

       ·Trace event 10046—擴充的SQL跟蹤；

       ·如果無法互動性的監控事件，可以透過紀錄等待事件到跟蹤檔案進行診斷效能問題；

       ·可以在例項（Event=“10046 tace name contex forever, level 8”， 永遠不要這麼做）/會話級別（Alter session set events ‘10046 trace name context forever, level 8’）啟用。

       ·執行要跟蹤的SQL；

       ·Alter session set events ‘10046 trace name context off’；

 

       ???以下過程在可能沒有。

       ·也可以使用dbms_support.start_trace進行跟蹤；

       ·跟蹤其他會話：Exec dbms_support.start_trace_in_session(sid=>xxx, serial#=>xxx, waits=>true, binds=>true);

       ·結束跟蹤：stop_trace_in_session；

 

       ·跟蹤檔案的位置在user_dump_dest 目錄下；

·可以使用tracefile_identifer命名跟蹤檔名，Alter session set tracefile_identifier= ‘Tracefilesql1’；

·然後使用tkprof工具進行格式化輸出，最近Metalink上有一個新的工具TRCA，更加適合分析跟蹤檔案。

     

OWI的限制

       ·沒有CPU 統計；

       ·非端到端的可見性；

       ·沒有歷史資料；

       ·由於當前計算機速度的飛增，一些計算可能不精確；

 

常見的等待事件

       ·Buffer busy waits：10g中更改為read by other session；引數中P1代表塊所在的檔案號，P2代表實際的塊號，P3在9i中代表reason for the wait，10g中代表v$waitstat中的CLASS列；等待時間為1s或100cs。

       ·Control file parallel write：引數中P1代表塊駐留的絕對檔案號，P2代表總塊數，P3代表I/O請求數量；等待時間為完成所有I/O請求的實際延遲。

       ·Db file parallel read：當一個程式從一個/多個資料檔案讀取多個不連續的塊，或資料庫恢復時有些資料庫塊需要恢復時會發生這種事件；引數P1代表需要讀取的檔案數，P2讀取的總塊數，P3代表I/O請求的總數量；等待時間為完成所有I/O請求的實際延遲。

       ·Db file parallel write：當DBWR以批模式些藏塊到資料檔案時會發生；引數中P1代表需要寫入的檔案數，P2代表要寫的總塊數，P3（9.2+）以百分之一秒為單位代表超時的值；等待時間：無超時。

       ·Db file scattered read：通常在全表掃描時發生；引數P1代表開始讀取的塊的檔案號，P2代表開始讀取的塊號，P3代表讀取的塊數；等待時間：無超時。

       ·Db file sequential read：當從索引，回滾段，表（ROWID），資料檔案頭，一些臨時段讀取時會發生該事件；引數P1代表開始讀取的塊的檔案號，P2代表開始讀取的塊號，P3通常為1，但是臨時段則大於1；等待時間：無超時。

       ·Db file single write：當Oracle更新資料檔案頭時發生該事件，通常在檢查點期間。如果資料庫有大量資料檔案可能會注意到這種情況；引數P1代表寫入的檔案號，P2代表開始寫入的塊，P3通常為1；等待時間：無超時。

       ·Direct path read：當oracle直接讀取資料庫塊到會話PGA而不是SGA的緩衝快取時時發生，直接路徑讀取通常在訪問臨時段時使用；引數P1讀取的所在的絕對檔案號，P2代表開始讀取的塊號，P3則為讀取的塊數；等待時間：無超時。

       ·Direct path write：與Direct path read相反，Oracle從PGA寫緩衝到資料檔案，通常用來寫到臨時段，直接資料載入或並行DML操作。

       ·Enqueue：是一種Oracle用來序列化訪問資料庫資源的共享記憶體結構，程式為了得到該enqueue鎖必須等待在佇列中。用來序列訪問資源的各種enqueue包括：ST，空間管理；SQ，序列號；TX，事務；引數P1代表正在等待的程式請求的enqueue名和模式，P2代表請求的鎖的資源識別符號ID1，P3代表請求的鎖的資源識別符號ID2；等待時間：依賴於enqueue名，Oracle最多可以等待三秒，或直到enqueue資源可用。

       ·Free buffer waits：當會話無法在資料庫緩衝快取中找到空閒緩衝讀入塊或者建立一致性讀時將發生該事件。這會喚醒DBWR釋放髒緩衝；引數中P1代表檔案號，P2代表需要讀入到快取中的塊號，P3（9i未使用），10G顯示緩衝快取中LRU列表的id；等待時間：Oracle最多等待1s，然後重試。

       ·Latch free：當程式等待一個當前被其他程式佔用的latch時會發生這種事件。程式要得到latch不必等待在佇列中。最常見的latch包括：cache buffer chains, library cache和shared pool；引數P1代表latch的地址，P2代表latch號（v$latchname.latch#），P3代表嘗試的次數；等待時間：指數增長，10G中latch由其自身的等待事件。

       ·Library cache pin / library cache lock：當會話試圖將一個物件“釘“在庫快取中以更改或測試它時會發生該事件，必須得到一個釘確保物件不會被改變；P1代表庫物件地址，P2代表載入鎖的地址，P3為模式+名字空間（來自v$db_object_cache）；等待時間：PMON為1S，其他程式為3S。

       ·Log buffer space：當程式必須等待日誌緩衝中的空間可用時發生；未使用引數；等待時間：1S，如果必須等待日誌切換則為5S。

       ·Log file parallel write：會話等待LGWR寫日誌緩衝塊到重做組成員時發生；引數P1代表要寫入的日誌檔案數，P2代表要寫入的OS塊數，P3代表I/O請求數量；等待時間：實際的延遲。

       ·Log file sequential read：當程式等待塊從線上重做日誌檔案讀取時會發生該事件；引數P1代表重做日誌檔案的相對序列號，P2代表開始讀取的塊號，P3代表讀取的OS塊數；等待時間：實際的延遲。

       ·Log file switch (archiving needed)：指示ARCH 跟不上LGWR。

       ·Log file switch (checkpoint incomplete)：檔案歸檔前檢查點必須完成，指示重做日誌檔案可能太小。

       ·Log file sync：引數P1代表需要同步的日誌緩衝中的緩衝的數量；等待時間：1S。

       ·SQL*Net message from/to client：如果很大，可能指示網路有問題；P1：顯示網路驅動器的型別，P2代表位元組數，P3未使用。等待時間：實際的延遲。

       ·跟蹤CPU和其他統計：V$SESSTAT / V$SYSSTAT，其中包含了

–         CPU used by this session

–         CPU used when call started

–         Recursive CPU usage

–         Parse time CPU

–         Session logical reads

–         Physical reads

–         Physical writes

 

等待事件：根本原因分析

       ·需要收集等待事件統計歷史；

       ·Trace 10046，會有很大的負載但是可以得到最小粒度的效能資料；

       ·Statspack，不能得到會話級別的資料；

       ·使用BEFORE LOGOFF TRIGGER收集歷史資料—低負載（如果會話被KILL或掛起則沒有任何資料）。建立表並保持大約7天的資料，可以歸檔這些資料進行長期比較。將等待事件和產生該事件的SQL語句（V$SQLTEXT）儲存起來。

文章出處：DIY部落()