cpu time 分析

kamus在他的blog10gRAC培訓 - 2 and last。說到了這個cpu time，具體可以看正文以及下面我與他的留言，他的意思其實就是：

不是說他的不對，只是比較覺得這句話太容易誤導別人，所以，給一些補充建議，我同意如果有很明顯的其它事件，而cpu time不明顯的時候，可以優先處理其它事件。但是，還有以下2個地方需要注意：

1、cpu time高一般代表系統的邏輯讀大，或者是高計算型的東西，如case函式，decode函式，自定義的計算型別函式等等，把cpu給耗光了，但是這個時候可能根本沒有其它等待事件。這樣是否證明這個系統很好呢？很可能是，非常不好，因為他很有可能沒有必要有這麼多的邏輯多，或者是，沒有必要有這麼多的cpu密集型計算就可以完成的任務，現在消耗這麼CPU Time就是不正常的，很容易導致系統負載異常。

2、至於wait time，比如OLTP環境上最典型的db file sequential read引起的等待，是因為發生了物理io而引起的，而很多時候，物理讀是隨邏輯讀增加而增加的，而邏輯讀可能會導致cpu time高，也就是說，cpu time與wait time一般是同時增加的。特別是比較高訪問量，大資料量，大SGA的系統，邏輯讀與物理讀都比較高，除了cpu time與db file sequential read，可能不會有很明顯的其它等待事件，而優化的結果可能是cpu time與wait time同時減少。

既然說到了db file sequential read，也解釋一下這個事件，與cpu time一樣，很多時候說明系統是比較正常的，一個優化非常良好的系統，很可能第一個等待事件就是它。因為沒有一個系統，不會發生任何物理IO，既然有物理IO，當然db file sequential read就是最好的了，一般表示讀資料正常。同樣的理由，db file sequential read大了，也可能預兆系統有不該有的物理讀發生了。

如一個看起來很正常的sql語句，單個語句效率看起來並不差，執行時間已經小於0.01秒。假定原來邏輯讀每個語句平均是100個，物理讀平均10個，執行次數每小時50萬次，優化完成以後，邏輯讀降低為平均50個，物理讀平均5個，那麼，每小時降低的邏輯讀總量就是50*50w=2500w個，降低的物理讀為5*50w=250w個。那麼再假定每個cpu每秒處理100000個邏輯讀就達到了極限，每個物理讀需要等待8ms，那麼，就可以減少約2500w/100000*3600=7%的CPU使用率（單CPU），可以減少250w*8ms=20000秒的總io wait time。

同理，如果能採用同樣的方法，減少執行次數從每小時50w到每小時25w，則收到的效果是一樣的。

評價這個cpu time與db file sequential read是否正常，需要很多調優的經驗，不過，需要記住的是，任何情況下，不要絕對的說好還是不好。最好的方式就是從statspack或者是awr上看看，排在cpu time，或者是物理讀top的語句，他們是否應當有這麼大的消耗，他們是否應當執行這麼多的次數。