探索系列——神人steve adams之著oracle8i interal service(六）

latch contention
 
    我們已發現oracle希望latch總是短暫持有。如果對於任何latch使用並未採用此種方式，很可能發生了latch contention.
當一個latch被一個程式持有，但同時多個程式也需要它，就產生了latch contention.直至積累下來的需要皆處理完，等待程式
必須競爭這個latch.這樣導致無效使用cpu time,甚至對效能造成相當大的影響.
    競爭某個特定的latch所產生的結果，透過頻度，持續時間及latch contention episode的強度來衡量它.v$latch的sleep1及sleep2
列的sleep count歷史柱狀圖可以對此進行評估.注意：如果sleep cycles重複次數多於4次，不會儲存它的統計資訊.sleep5-sleep11儲存下
僅是為了相容oracle7.3之前的版本.
    sleep counts的柱狀圖，可以確定效力（或無效），以此減少對於latch contention.但是sleeps/gets值為latch tuning提供一個很好的參考.



latch levels
   oracle程式需要同時持有許多latch。因此，會出現這種可能性：latching deadlocks問題，持有latch a的程式和持有latch b的程式，這兩個程式都在spinning
等待另一個latch.oracle為了避免出現這種情況，latches始終以定義好的順序獲取，當需要多個latch時。為了支援這種情況，oracle中的每個latch有一個位於15之間的level,每個程式會專門為此維護一個2-byte的點陣圖，以此表示這個程式
目前持有latch的level是多少.當一個程式嘗試以樂觀方式get a latch時，會檢查一下確保這個latch沒有以相同的level被其它程式佔有，或者更高階別持有.一般來講，如果違犯這種機制，ora-600[504]錯誤會丟擲.
  (注：但是這種latch level 規則有時可以適量放鬆，允許兩個library cache child latches同時被持有)
對於像redo allocation latch(level 6)高階別latch的contention,會加劇對於像cache buffers chains latches（oracle8.1是level1)低階latch的contention.會發生這個是因為需要高階latch的程式必須等待，當它持有一個低階latch時。因此，
低階latch會比正常情況下持有時間更長。v$latch的 waits_holding_latch就是最好的指示燈。這個統計表示當它持有這種latch，等待的次數.這些等待次數也包含，但不限於，等待一個高階的latch.比如，等待cache buffers chains latches產生的latch 統計資訊，
包含了sleeps，當嘗試獲取redo allocation latch時.但是，它也包含其它一些如log buffer space waits的等待次數(waits).這些waits應該首先被考慮。因此，正常情況下，根據latch level以降序方式考慮這些latch contention問題是最明智的。



no-wait mode 不等待模式
   它適用於：oracle已持有一個latch,並且想以同級或低階得到另一個latch.樂觀等待模式不能用於這種情況，因為需要防止出現死鎖。這種情況下，oracle以no-wait mode請求一個latch,只要這對latches已同級模式持有.如果no-wait 請求成功，就不會出現死鎖，這樣最好。但如果請求失敗，
就會出現這個程式繼續堅持請求這個latch，進而生了deadlock.相反，這個程式會release所有的高階latch(已持有的），讓出cpu資源，然後馬上再次以正常的級別次數請求latch.
    redo copy latch就屬於這種特殊情況。no-wait mode用於latch get的大多數情況，因為oracle用它們可以保護把資料複製到log buffer這個動作.如果請求redo copy latch失敗，oracle會在另一個redo copy latch實現它。樂觀等待模式只用於no-wait mode請求所有其它的redo copy latch失敗，
才會用到樂觀等待模式.這是一種正常的等待情況，當持有redo copy latches時，比如競爭高階的latch,透過加大_log_simultaneous_copies不會起到什麼作用.
除了redo copy latch外，oracle有時會以no-wait mode get一些型別的latch.對於所有其它型別的latch,v$latch immediate_gets和immediate_misses始終為0.

    從效能角度出發，immediate misses並不表示具有效能問題。如果滿足樂觀等待請求的條件，放棄的latch被重新利用或獲取，這時immediate miss的成本就不會顯得不過分.
但是，如果發現對於其它一些latch出現競爭,那麼immediate misses增加了對於這些latch的負荷,就會加劇這種情況.因此，調優任何latch，你應該想法減少immediate misses和sleeps.但是，不要失去過多的sleep(相對於immediate misses)，除非是對於一些高階的latch等待太多.



latch cleanups
    現實存在oracle的程式有時會意外死亡，或者當它持有一個latch時死亡.oracle pmon程式的工作就是檢測哪些使用者程式意外死亡，並實行清除工作.在這個清除工作過程中，pmon會首先執行latch cleanup.latch cleanup先處理完所有新增的已故程式，然後開始rollback未提交的事務.

    latch cleanup並不僅僅是一個free latch的問題。latch是用來運算元據結構的，如果一個持有latch的程式意外死亡，很可能latch所保護的資料結構可能會出現不一致的情況。為了支援latch recovery,持有latch的程式為了操作一個資料結構，先寫一條資料操作的記錄資訊到對應於這個latch的latch recovery area中，然後
實行操作(運算元據結構）.pmon的工作不僅僅是free latch,還要恢復被latch保護的資料結構.如果latch recovery需要進行或正在操作之中，我們說這個latch處於flux.

     但是，因為pmon正常情況下是每3 second喚醒一次，oracle也有另一種發起latch clearup的方法.如果一個程式多次重複依舊得不到latch,它將實行一個latch activity test,分析是否有必要進行latch cleanup.如果在5 centisecons的時間內，沒有任何latch的活動，程式就會通知pmon,pmon將檢查持有latch的程式是否死亡，及有無必要被清除.
當一個程式正在執行一個latch activity test時，或者等待pmon程式檢查持有latch的程式，v$session_wait顯示一個latch activity wait的相關資訊。


   wait parameters(latch activity waits)
引數                                    描述
p1                                      請求latch的sga address
p2                                      latch型別
p3                                      0表示latch activity test。否則，pmon會檢查可能已故持有latch的程式號


  如果latch contention伴有大量latch activity waits,這兩種問題的原因，可能是os的排程問題（它阻止latch持有者快速方式free latch)