探索系列_神人steve adams之著oracle8i interal service(二）

waits 等待
  oracle例項有好多程式（或者每個程式有許多執行緒）在一起工作，它們必須要相互通訊。它們通訊的方式是採用semaphores(訊號量），類似於
鐵道上的訊號燈，告訴火車是否可以開動或停止，何時可以開啟或停止.其實oracle服務程式經常也需要停止或者等待
   
   停止或等待的情形如下：
     某種資源不可用
     目前沒有工作可作
     有時它們需要等待其它的服務程式完成必備的工作或任務


sepaphores 訊號量(燈）
  oracle伺服器程式有一個對應的訊號量，程式需要某種資源時，等待它們的訊號量，或者要作工作，或需要它的工作完成之時。
當它們需要的資源可以用，或它們可以開始工作，或它們前提工作已經完成了，然後訊號量就會發一個訊號，你們不用再等待了.

  比如，lgwr可能會等待完成某項工作的訊號量，是這樣一種情形，當一個使用者程式拷重作資料到redo log buffer。當使用者提交時，
lgwr必須把重作和提交標誌的相關資訊寫到log file（此時使用者在等待）.
為了實現這個目標，使用者程式給lgwr程式丟擲一個訊號量，表示lgwr可以停止等待某個工作，因為現在可以作這些工作了.這時，使用者
程式等待它的訊號量.當log file i/o完成了，lgwr傳送一個訊號量，告訴使用者程式，你啊，現在可以繼續產生新的事務，因為提交操作已經
完成了。最後lgwr又等待它的訊號量，因為它又沒有更多的工作可以作了。


  另一種情況，程式a可能要更新一個記錄，但發現程式b對這個記錄在以前作過更改，但沒有提交。此時程式a必須等待程式b完成提交。為了實現這個,
程式a將等待它的訊號量。當程式b提交，它傳送一個訊號量告訴程式a，你可以完成你的更新操作了.
 


  semaphore facilities 訊號量工具
     它是一種作業系統的工具。當oracle程式等待它的訊號量時，按照os的講法，os不會排程cpu的資源給它用。這時，這個oracle就叫阻塞，不能執行。直至重新得到訊號量。
現在一些作業系統支援多種型別的訊號量。system v訊號量用得最多。system v訊號量的資料結構，根據semmns核心引數定義的大小，會在核心記憶體中構成一個固定的陣列（陣列）.
為了瞭解（傳送）一個訊號量的訊號或等待，程式必須使用semop()系統呼叫.因為實現他們要透過作業系統的核心，system v訊號量會導致非常高的不必要的系統呼叫上下文切換成本
，由於訪問核心資料結構的序列式方法，也造成低效的伸縮性（系統）.
     為了實現更好的效能和靈活性,好多作業系統也提供一種對於訊號量操作的替代方法。其實就是透過一種偽裝置驅動來實現，叫作一個post-wait driver(譯為：等待後的驅動）.
這些訊號量的資料結構是駐存在使用者的程式中，而非核心的記憶體中，因此操縱它們其實是在使用者的上下文環境之中的偽裝置驅動.這樣就會減少系統呼叫上下文切換的次數，提升了伸縮性，
但是這一切皆與特定的os有關.
     posix實時擴充套件委員會，一致同意使用者記憶體訊號量工具的使用。posix.1b標準（以前是posix.4)定義如何實現記憶體訊號量工具的優雅與高效的必備條件，包括：實現介面與實施預備條件
而不涉及它的可移動性。posix.1b訊號量現在大多os皆支援.

     oracle到底使用哪位訊號量工具，與os和特定版本有關。如果oracle安裝手冊，描述瞭如何配置semmns核心引數，這意味著預設會使用system v訊號量.不幸的是，大多會把semmns設定為200，
根據沒去考慮oracle程式到底需要多少數量，或者其它的系統及應用軟體的相關要求,我認為這是自以為是。我認為你要給每個oracle程式分配一個訊號量，當然也要想到其它的程式要求.你也應該
意想到，在一些平臺上，每個訊號量要在單一的訊號量集中進行分配。因此要為每個例項設定semmni引數（表示訊號量的標識）,另外semmsl（如何定義）絕對至少等待oracle的引數processes值。
有必要開啟vector posts，主要像lgwr,dbwn後臺程式會使用它，為了傳送（發解）單一訊號量操作之中的多個等待程式，vector posts的使用與_use_vector_posts引數有關


     而且，如果在os中semmnu核心引數，它應大於os層面併發的訊號量大小.對於像許多訊號量客戶端程式的系統，預設配置肯定是不夠的。這樣訊號量操作會在業務高峰出現間斷，返回ora-7264或ora-7265錯誤.
為了避免這個，semmnu引數至少要等於cpu的個數加上cpu執行佇列的峰值長度

    

system v訊號量引數

引數名                                 描述
semmns                                 定義系統中的訊號量數量.除了os必須的及其它軟體的訊號量，你應該至少為每個
                                       oracle例項的伺服器程式分配一個訊號量.也就是說至少等於processes的值.如果使用訊號量的客戶端
                                       並未嚴格遵守實行關閉和啟動，你應額外至少配置它的值等於最大的oracle例項的訊號量的值


                                       再者，核心引數可以控制一個指定的使用者（經常是maxup核心引數）最多可以同時使用的程式數,它應當至少等於
                                       semmns的配置，同時也要想到oracle使用者下面一些不需要訊號量的管理程式的存在。但是，這個引數不要配置太大，導致產生
                                       其它使用者建立太多的程式，導致核心程式表會填滿的風險.因此，控制所有使用者（經常是nproc核心引數）最大的併發程式數的引數，至少
                                       三倍於semmmns的值


semmsl                                 每個單一訊號量集的大小限制。這個引數一般在大多os中不用定義。哪果它定義了，oracle需要會把例項的所有訊號量分配在一個訊號量集中，這個引數
                                       至少等於任何例項最大的processes的值。



semmni                                 系統中訊號量集的識別符號個數。除了os的必須及其它軟體外，你應為每個例項分配一個，或者說，要分配更多，如果semmsl引數配置了，這樣任何一個例項需要多個訊號量集.





semmnu                                 系統中撤消結構的訊號量的個數。當在訊號量操作中出現一個程式的意外死亡，用撤銷結構恢復核心訊號量資料結構。這個引數的值要大於峰值時刻正在執行及執行著程式的個數






  如果在os中，oracle預設使用system v訊號量,同時也支援一個post-wait driver的使用，這時你應使用post-wait driver。
 
正常use_post_wait_driver的值為true，有時設定post_wait_device也是必須的。






 scheduling latencies  調節延遲(兩命令之間的反應間隔）

   當一個程式接到訊號量的通知，它的os狀態從阻塞變成可以執行。但這並不意味著cpu排程會把資源馬上給它使用。它必須至少等待
到os程式排程器下一次執行才可以，這個等待時間也可能更少，如果比它更高最佳化級的程式等待著執行。從一個程式接到訊號量的通知（可以執行）直到它開始真正執行的
的時間間隔，叫作排程延遲.排程延遲主要體現在oracle反應時間上。因此減少它對於oracle調優至關重要.
   大多數os排程器演算法會動態根據正在執行的程式目前消耗的cpu time，調整程式的執行優先順序.在非常繁忙的oracle環境中，這種配置可能對oracle一些關鍵的後臺程式，比如:lgwr,dwn,lckn,lmdn的執行優先順序
產生不良影響.這樣無形就會增加這些程式的排程器延遲,甚至可能在極端情況下影響基於後臺程式的服務產生極大的bottlebock.

   大多數os支援多種排程器演算法。在可能情況下，選擇不影響程式執行優先順序的排程器演算法。如果不行，os會採用一個預設的排程器演算法。如果一個程式的優先順序固定了，它會不被降級。在大多數情況下，所有使用者可以使用
優先順序固定的功能，oracle會自動採用此功能。在其它一些情況下，只有sa及特有許可權的使用者可能用它。

  
   timeouts  超時
  oracle伺服器程式不會無限期的等待下去，以免它們無限期等待下去。幸運的是，訊號量的等待可以被中斷（打斷）。因此假如oracle程式開始等待它的訊號量時，它會設定一個警告時鐘上，以此安排它的睡眼能被中斷,或者叫超時。
假如某個程式接到通知，它就把alarm clock的狀態置為off(關閉），然後繼續處理下面的工作。但是，如果超時過期，等待透過一個sigalrm訊號量中斷它。此時這個程式就會重新分析及評估它的相關情況與資源，決定是否繼續等待
比如，等待一個入隊鎖的程式，可能發現了死鎖，此時等待超進了。如果發現了一個死鎖，語句將被回滾，並觸發一個異常，但如果不是這種情況，程式將重新配置一個新的延遲，繼續再次等待它的信量號.



   有時有這樣一種情況，延遲在過期前，一個程式時間在非常短的時間就接到通知，alarm進行入睡就像程式嘗試關閉它.這種情況，oracle的相關程式會把一個資訊寫到它的trace file中: ignoring sigalrm

如果你在一些trace file發現這些資訊，並沒有什麼有用的資訊。它只是告訴你，等待程式有時並沒有像它們所想的速度一樣快速的被通知，不管如何，等待事件你總要時時關注




    wait statistics  等待統計
  oracle等待統計很有價值，但也不要過高估計它們的作用。如果發現oracle大量等待資源：比如latch,free cache buffers,enqueue locks等，這時等待統計能同時確認這個效能問題。經驗越多，你也可以用它確認網路及磁碟的效能問題.
等待統計為你解決這些問題提供一個非常有價值的參考.
  但是如果你的應用發現過多的解析，或者發現與你的工作負荷不一致的大量的disk i/o。這時等待統計就用不上了。它們表現得好像非常健康，好像也確實如此。等待統計只能揭示資料服務層及以下層的低效問題，它們並不適用於診斷應用層的效能問題
，由此導致 增加了資料庫服務的負荷，但這個問題並不會讓工作低效工作.