Oracle效能測量體系（commit Time)

     在高事務併發的業務系統中,commit time是Oracle的巨大傷痛所在，commit time是目前為止Oracle最大的序列化所在，其處理能力直接決定了資料庫可以處理多少負載。特別在database link環境中，commit time會帶來致命的殺傷力，這也是在database link環境中無法做到高併發的基本原因之一。

     Commit Time:= Commit CPU + Commit Queue Wait
                         := Commit Queue Wait

     在commit階段，可以認為Server process很少會消耗CPU資源，消耗的CPU僅僅是lgwr程式的CPU資源，其主要消耗在於Waiting，等待lgwr程式完成工作並喚醒我。

     Commit Time:= redo sync time
                         := log file sync
                         := redo write time + other waiting time
    
    commit的吞吐量指標由以下幾個：
    transaction
    redo sync writes
    redo writes or redo bytes
  
   我們這裡選擇redo sync writes作為主要的吞吐量指標，以transaction作為輔助性指標。

   要保證commit的高效運轉，需要確保各個部件完全的高效運轉：
  （1）、lgwr程式具有足夠的CPU資源
              CPU ratio,CPU Queue,lgwr CPU ratio，當CPU資源緊張的時候可能需要lgwr和CPU進行繫結，使其更加高效的運用CPU。
              當併發量越大，越需要具有強勁的CPU能力使lgwr可以進行快速的通知處理。
  （2）、redo log file具有足夠用的IO吞吐量
              log file parallel write，必須足夠快，什麼叫做足夠快，也就是沒有尋道時間，沒有定位時間，只有寫入時間，一般情況下應該小於1ms。
             任何大於1ms的觀察都意味著redo log file存在爭用。對於具有大容量快取記憶體的磁碟系統，也許總是應該是0ms。
  （3）、足夠快的lgwr頻率確保lgwr不會產生寫過大的IO量
             每次redo write的bytes數量，要保持相對穩定redo writes的bytes數量，總是需要寫過大的值，表示lgwr速度跟不上。
             或者redo sync writes和 redo writes的比較，當redo sync writes和redo writes的差異比較大的時候，表示lgwr程式慢。
  只要redo log file在磁碟裡，其處理能力總是有限的。在達到commit極限的時候，最為有效的辦法就是減少事務數量。

   
  反正都比較凌亂，本來是想通過主要的RT指標，以及這些RT指標的影響因子來確定的，畢竟這裡僅僅是整理思路使用，所以大規模簡化了。

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