效能優化 - Oracle Tuning 總結 2-2

 

latch free: latch釋放
latch 是一種低階排隊機制，用於保護SGA 中共享記憶體結構。
latch就像是一種快速地被獲取和釋放的記憶體鎖。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%時，就應當研究這一問題。
Oracle 的 latch 機制是競爭，其處理類似於網路裡的CSMA/CD，所有使用者程式爭奪latch， 對於願意等待型別(willing-to-wait)的latch,如果一個程式在第一

次嘗試中沒有獲得latch,那麼它會等待並且再嘗試一次,如果經過_spin_count 次爭奪不能獲得latch, 然後該程式轉入睡眠狀態，持續一段指定長度的時間，然

後再次醒來，按順序重複以前的步驟.在8i/9i 中預設值是 _spin_count=2000。
如果SQL語句不能調整，在8.1.6版本以上，Oracle提供了一個新的初始化引數: CURSOR_SHARING，可以通過設定CURSOR_SHARING = force 在伺服器端強制繫結變

量。設定該引數可能會帶來一定的副作用，對於Java的程式，有相關的bug，具體應用應該關注Metalink的bug公告。

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

即FIFO（先進先出）排隊機制。
Enqueue 等待常見的有ST、HW 、TX 、TM 等
ST enqueue 用於空間管理和字典管理的表空間(DMT)的分配。對於支援LMT 的版本，可以考慮使用本地管理表空間，對於Oracle8i，因為相關bug 不要把臨時表

空間設定為LMT. 或者考慮預分配一定數量的區。
HW enqueue 指段的高水位標記相關等待；手動分配適當區段可以避免這一等待。
TX 是最常見的enqueue 等待。TX enqueue 等待通常是以下三個問題之一產生的結果。
第一個問題是唯一索引中的重複索引，你需要執行提交（commit）/回滾（rollback）操作來釋放enqueue。
第二個問題是對同一點陣圖索引段的多次更新。因為單個點陣圖段可能包含多個行地址（rowid），所以當多個使用者試圖更新同一段時，等待出現。直到提交或回滾，

enqueue 釋放。
第三個問題，也是最可能發生的問題是多個使用者同時更新同一個塊。如果沒有自由的ITL 槽，就會發生塊級鎖定。通過增大initrans 和/或maxtrans 以允許使用

多個ITL 槽，或者增大表上的pctfree值，就可以很輕鬆地避免這種情況。
TM enqueue 在DML 期間產生，以避免對受影響的物件使用DDL。如果有外來鍵，一定要對它們進行索引，以避免這種常見的鎖定問題。

Log Buffer Space: 日誌緩衝空間
當你將日誌緩衝（log buffer）產生重做日誌的速度比LGWR 的寫出速度快，或者是當日志轉換（log switch）太慢時，就會發生這種等待。為解決這個問題，可

以增大日誌檔案的大小，或者增加日誌緩衝器的大小.
另外一個可能的原因是磁碟I/O 存在瓶頸，可以考慮使用寫入速度更快的磁碟。

log file switch (archiving needed)
這個等待事件出現時通常是因為日誌組迴圈寫滿以後，第一個日誌歸檔尚未完成，出現該等待可能是 IO 存在問題。
解決辦法：
可以考慮增大日誌檔案和增加日誌組
移動歸檔檔案到快速磁碟
調整log_archive_max_processes .

log file switch (checkpoint incomplete): 日誌切換（檢查點未完成）
當你的日誌組都寫完以後，LGWR 試圖寫第一個log file，如果這時資料庫沒有完成寫出記錄在第一個log file 中的dirty 塊時（例如第一個檢查點未完成），

該等待事件出現。
該等待事件說明你的日誌組過少或者日誌檔案過小。
你可能需要增加你的日誌組或日誌檔案大小。

Log File Switch: 日誌檔案轉換
所有的提交請求都需要等待"日誌檔案轉換（必要的歸檔）"或"日誌檔案轉換（chkpt.不完全）"。確保歸檔磁碟未滿，並且速度不太慢。DBWR 可能會因為輸入/

輸出（I／O）操作而變得很慢。你可能需要增加更多或更大的重做日誌，而且如果DBWxR 是問題癥結所在的話，可能需要增加資料庫書寫器。

log file sync: 日誌檔案同步
當一個使用者提交或回滾資料時，LGWR 將session 會話的重做由redo buffer 寫入到重做日誌中。
log file sync 必須等待這一過程成功完成(Oracle 通過寫redo log file 保證commit 成功的資料不丟失)，這個事件說明提交可能過於頻繁，批量提交可以最

大化LGWR 的效率，過分頻繁的提交會引起LGWR頻繁的啟用，擴大了LGWR 的寫代價。
為了減少這種等待事件，可以嘗試每次提交更多的記錄。
將重做日誌置於較快的磁碟上，或者交替使用不同物理磁碟上的重做日誌，以降低歸檔對LGWR的影響。
對於軟RAID，一般來說不要使用RAID 5，RAID5 對於頻繁寫入得系統會帶來較大的效能損失，可以考慮使用檔案系統直接輸入/輸出，或者使用裸裝置（raw

device），這樣可以獲得寫入的效能提高。

log file single write
該事件僅與寫日誌檔案頭塊相關，通常發生在增加新的組成員和增進序列號時。頭塊寫單個進行，因為頭塊的部分資訊是檔案號，每個檔案不同。更新日誌檔案

頭這個操作在後臺完成，一般很少出現等待，無需太多關注。

log file parallel write
從log buffer 寫redo 記錄到redo log 檔案，主要指常規寫操作(相對於log file sync)。
如果你的Log group 存在多個組成員，當flush log buffer 時，寫操作是並行的，這時候此等待事件可能出現。
儘管這個寫操作並行處理，直到所有I/O 操作完成該寫操作才會完成(如果你的磁碟支援非同步IO或者使用IO SLAVE，那麼即使只有一個redo log file member,也

有可能出現此等待)。
這個引數和log file sync 時間相比較可以用來衡量log file 的寫入成本。通常稱為同步成本率。

control file parallel write: 控制檔案並行寫
當server 程式更新所有控制檔案時，這個事件可能出現。
如果等待很短，可以不用考慮。如果等待時間較長，檢查存放控制檔案的物理磁碟I/O 是否存在瓶頸。
多個控制檔案是完全相同的拷貝，用於映象以提高安全性。對於業務系統，多個控制檔案應該存放在不同的磁碟上，一般來說三個是足夠的，如果只有兩個物理

硬碟，那麼兩個控制檔案也是可以接受的。在同一個磁碟上儲存多個控制檔案是不具備實際意義的。
減少這個等待，可以考慮如下方法：
減少控制檔案的個數(在確保安全的前提下)
如果系統支援，使用非同步IO
轉移控制檔案到IO 負擔輕的物理磁碟

control file sequential read/ control file single write
控制檔案連續讀/控制檔案單個寫
對單個控制檔案I/O 存在問題時，這兩個事件會出現。
如果等待比較明顯，檢查單個控制檔案，看存放位置是否存在I/O 瓶頸。
使用查詢獲得控制檔案訪問狀態：
select P1 from V$SESSION_WAIT
where EVENT like 'control file%' and STATE='WAITING';
解決辦法：
移動有問題的控制檔案到快速磁碟
如果系統支援，啟用非同步I/O

direct path write: 直接路徑寫
該等待發生在，等待確認所有未完成的非同步I/O 都已寫入磁碟。
你應該找到I/O 操作頻繁的資料檔案，調整其效能。
也有可能存在較多的磁碟排序，臨時表空間操作頻繁，可以考慮使用Local 管理表空間，分成多個小檔案，寫入不同磁碟或者裸裝置。

SQL*Net message from dblink
該等待通常指與分散式處理（從其他資料庫中SELECT）有關的等待。
這個事件在通過DBLINKS 聯機訪問其他資料庫時產生。如果查詢的資料多數是靜態的，可以考慮移動這些資料到本地表並根據需要重新整理，通過快照或者物化檢視

來減少跨資料庫的訪問，會在效能上得到很大的提高。

slave wait: 從屬程式等
Slave Wait 是Slave I/O 程式等待請求，是一個空閒引數，一般不說明問題。

2.2.4 High Load SQL 分析
對於一個特定的應用程式或者系統來講，要調整優化其效能，最好的方法是檢查程式的程式碼和使用者使用的SQL語句。
如果使用了 level 5 級別的 snapshot ，那麼statspack生成的報告中就會顯示系統中高負荷SQL語句（High Load SQL）的資訊，而其詳細資訊可以在

stats$sql_summary 表中查到。預設情況下 snapshot 的級別是 level 5。
按照 buffer gets, physical reads, executions, memory usage and version count 等引數的降序排列順序，把SQL語句分為幾個部分羅列在報告中。

2.2.5 報告的其他部分
statspack報告的其他部分包括了 Instance Activity Stats，Tablespace IO Stats，Buffer Pool Statistics，Buffer wait Statistics，Rollback Segment

Stats，Latch Activity，Dictionary Cache Stats，Library Cache Activity，SGA breakdown difference 以及 init.ora 引數，等等。目前本文不對這些內

容進行詳細討論，請參加其他詳細文件。

 

2.3 trace session

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