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

  tuning the spin count調優spin的次數

  顯然，增加_spin_count會提升spinning的效力，但這樣會花費一些cpu time在不必要的spins上。其實調節spin count的問題就是
如可權衡spinning花費的cpu time與避免上下文切換節省的cpu time。這裡有個法則，就是全力減少下面的值:
 _spin_count*sleeps/misses
這個公式就是spinning的成本.如果迷茫的話，就會加大spin count的值而不是選擇一個更小的值。如果一個oracle instance,
發現輕微的latching問題，加大_spin_count會有好處。在一系列的cpu機器上，假如許多活動程式對於這些cpu的權重或重要性是一樣的（優先順序），如此配置非常有用.
但發現一個例項出現相當嚴重的latch競爭，最優的spin count通常應小於預設的spin count值，而不是大於它.
 調節spin count你最好最後作，當你嘗試節所有的方法（比如找到latch).


sleeps 沉睡
  假如一個樂觀等待latch失敗，此時在這個程式沉睡之前，它必須安排再次醒來的一些事情。對於馬上沉睡（再次醒來）的一個程式，有兩種機制。latch sleeps的正常機制就是超時。
一個程式會沉睡，在latch等待一個訊號量，但在這樣作之前，它要設定一個alarm，用此在指定的間隔時間最後發出一個訊號.所指定的這個間隔是一個變數。隨著再次get latches的失敗，這個間隔值會加位增大.
這個間隔相關演算法是由_max_exponential_sleep控制，在oracle8中預設是2 seconds.但是，哪果這個程式已經佔用另一個latches,此時最大的沉睡時間減少為_max_sleep_holding_latch引數值,它預設為4 centiseconds,也可能根據這個程式所佔用的其它一些latches會更少

   程式在沉睡之前，要作的的另一件事就是更新v$session_wait的會話等待資訊，表明程式正在等待latch free事件完成

等待引數（latch free waits)

引數                                     描述
p1                                       所需latch的sga地址;查詢v$latch_parent及child得到
p2                                       latch的型別，對應v$latch的latch#
p3                                       嘗試得到一個latch之前，這個程式的沉睡次數



   如果一個程式以樂觀或悲觀模式get 一個latch再次失敗的話，它會更新v$latch_misses latch misses統計資訊.這個更新動作不被latch保護，因此這些統計資訊可能並不完全與v$latch同步。v$latch_misses的每行記錄一個latch可能從這個持有，nwfail_count及sleep_count列記錄
no-wait get失敗次數和沉睡次數.當持有一個特有位置的latch時，會發生這種情況.不幸的是，要相當精通了解用於解析分析這些統計重要性的oracle server 程式碼.



latch wait posting  這是另一種機制

  一個程式在get某個latch失敗後，沉睡之前，可能再次被對映的第二種機制或方法叫作它.採用這種配置，free這個請求latch的另一個程式將對映這個沉睡的程式.
等待程式必須請求latch wait posting，在它準備沉睡之前。透過把自己的相關資訊放入用於post的一系列程式列表之中（就是一個佇列，可以這樣理解）這樣實現它.
就是叫作latch wait list.當一個程式free a latch,它會檢查latch wait list,如果發現有一個程式在等待這個latch,它給這個等待程式傳送相應的訊號量.其實就相當於給os發一個訊號，這個等待程式可以執行了

   這種機制的好處就是，等待程式獲取latch的可能性更高，只要這個latch free掉.當然，對於它也有很大的成本，因為要維護latch wait list資料結構.這種資料結構是以在sga的程式表之簡單（單向）連結串列方式來實現(我們看到就是x$ksupr.ksllalaq).當然，還有一些其它的資料結構，這些列表必須被latch保護。
如果發現在某個地方大量使用latch wait posting,那麼latch wait list就會變得很大，導致latch wait list latch會長時間佔有，比一般情況.實際上，發現二級latch wait list latch的競爭很正常,基本出現於開啟latch wait posting機制，對於其它一些latch的嚴重競爭.

    預設latch wait posting只有要library cache和shared pool latches會開啟.設定_latch_wait_posting為1就可以禁用它，或者值為2可以啟用它.你調節這個值一定要三思.如library cache latch問題很嚴重，禁用它很有作用。但相反如果對於一些其它的latch競爭很中和，可以開啟它，這樣反而會提升效能.
甚至為所有的latch開啟它時，latch wait posting不一定總會對於cache buffers chains latch請求進行沉睡.
    v$latch waiters_woken列，表示一個waiter透過latch wait posting機制，被喚醒的次數.這個統計值實際會大於misses的個數，因為會發生一個被post的程式，並沒有得到latch,為何呢？原因就是在這個過程之中其它程式佔用了這個latch.




36page