Statspack之十三-Enqueue

來源:互聯網
上載者:User

原文出處:

http://www.eygle.com/statspack/statspack13.htm



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操作一個資料表時,其結構不能被更改)。


 

本文作者:
eygle,Oracle技術粉絲,來自中國最大的Oracle技術論壇itpub.
www.eygle.com是作者的個人網站.你可通過Guoqiang.Gai@gmail.com來聯絡作者.歡迎技術探討交流以及連結交換.

原文出處:

http://www.eygle.com/statspack/statspack13.htm


相關關鍵詞:
相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。