Statspack之十三-Enqueue貼)

enqueue是一種保護共用資源的鎖定機制。該鎖定機制保護共用資源，如記錄中的資料，以避免兩個人在同一時間更新 同一資料。enqueue
包括一個排隊機制，即FIFO（先進先出）排隊機制。

Enqueue等待常見的有ST、HW 、TX 、TM等

ST enqueue，用於空間管理和字典管理的資料表空間(DMT)的區間分配，在DMT中典型的是對於uet$和fet$資料字典表的 爭用。對於支援LMT的
版本，應該盡量使用本地管理資料表空間. 或者考慮手工預分配一定數量的區(Extent)，減少動態擴充
時發生的嚴重隊列競爭。

我們通過一個執行個體來看一下:

 DB Name         DB Id    Instance     Inst Num Release     OPS Host------------ ----------- ------------ -------- ----------- --- ------------------DB       40757346      aaa                 1 8.1.7.4.0   NO    server                Snap Id     Snap Time      Sessions                ------- ------------------ -------- Begin Snap:       2845 31-10月-03 02:10:16      46   End Snap:       2848 31-10月-03 03:40:05      46    Elapsed:                  89.82 (mins)對於一個Statspack的report,採樣時間是非常重要的維度，離開時間做參考，任何等待都不足以說明問題。Cache Sizes~~~~~~~~~~~           db_block_buffers:      51200          log_buffer:    2097152              db_block_size:      16384    shared_pool_size:  209715200...........Top 5 Wait Events~~~~~~~~~~~~~~~~~                                   Wait     % TotalEvent                                               Waits  Time (cs)   Wt Time-------------------------------------------- ------------ ------------ -------enqueue                                            53,793   16,192,686   67.86rdbms ipc message                                  19,999    5,927,350   24.84pmon timer                                          1,754      538,797    2.26smon timer                                             17      522,281    2.19SQL*Net message from client                   94,525      520,104   2.18          -------------------------------------------------------------在Statspack分析中，Top 5等待事件是我們最為關注的部分。這個系統中，除了enqueue 等待事件以外，其他4個都屬於空閑等待事件，無須關注。我們來關注一下enqueue等待事件，在89.82 (mins)的採樣間隔內，累計enqueue等待長達16,192,686cs,即45小時左右。這個等待已經太過顯著，實際上這個系統也正因此遭遇了巨大的困難，觀察到隊列等待以後，我們就應該關注隊列等待在等待什麼資源。快速跳轉的Statspack的其他部分，我們看到以下詳細內容:Enqueue activity for DB: DB  Instance: aaa  Snaps: 2716 -2718-> ordered by waits desc, gets descEnqueue            Gets      Waits---------- ------------ ----------ST                1,554      1,554          -------------------------------------------------------------我們看到主要隊列等待在等待ST鎖定，對於DMT，我們說這個等待跟FET$,UET$的爭用緊密相關。我們在回過頭來研究捕獲的SQL語句:-> End Buffer Gets Threshold:   10000-> Note that resources reported for PL/SQL includes the resources used by   all SQL statements called within the PL/SQL code.  As individual SQL   statements are also reported, it is possible and valid for the summed   total % to exceed 100  Buffer Gets    Executions  Gets per Exec  % Total  Hash Value--------------- ------------ -------------- ------- ------------      4,800,073       10,268          467.5    51.0   2913840444select length from fet$ where file#=:1 and block#=:2 and ts#=:3        803,187       10,223           78.6     8.5    528349613delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and ext#=:4        454,444       10,300           44.1     4.8   1839874543select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and ext#=:4         23,110       10,230            2.3     0.2   3230982141insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)         21,201          347           61.1     0.2   1705880752select file# from file$ where ts#=:1....          9,505           12          792.1     0.1   1714733582select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t where t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0          6,426          235           27.3     0.1   1877781575delete from fet$ where file#=:1 and block#=:2 and ts#=:3 

我們看到資料庫頻繁操作UET$,FET$系統資料表已經成為了系統的主要瓶頸。至此，我們已經可以準確的為該系統定位問題，相應的解決方案也很容易確定，在8.1.7中，使用LMT代替DMT，這是解決問題的根本辦法，當然實施起來還要進行綜合考慮，實際情況還要複雜得多。

 

HW enqueue指和段的高水位標記相關等待；手動分配適當區可以避免這一等待。

TX鎖（事務鎖）是最常見的enqueue等待。TX enqueue等待通常是以下三個問題之一產生的結果。
第一個問題是唯一索引中的重複索引，你需要執行提交（commit）/復原（rollback）操作來釋放enqueue。
第二個問題是對同一位元影像索引段的多次更新。因為單個位元影像段可能包含多個行地址（rowid），所以當多個使用者試圖更新同一段時，可能一個
使用者會鎖定其他使用者請求的記錄，這時等待出現。直到獲得鎖定的使用者提交或復原， enqueue釋放。
第三個問題，也是最可能發生的問題是多個使用者同時更新同一個塊。如果沒有足夠的ITL槽，就會發生塊級鎖定。通過增大initrans和/或maxtrans以允許使用多個ITL槽（對於頻繁並發進行DML操作的資料表，在建表之初就應該考慮為相應參數設定合理的數值，避免系統運行以後線上的更改，在8i之前，freelists等參數不能線上更改，設計時的考慮就尤為重要），或者增大表上的pctfree值，就可以很容易的避免這種情況。

TM enqueue隊列鎖在進行DML操作前獲得，以阻止對正在操作的資料表進行任何DDL操作(在DML操作一個資料表時，其結構不能被更改)。

 

轉自：http://www.eygle.com/statspack/statspack13.htm