對Oracle效能統計中的資料解釋

《Oracle大型資料庫系統在AIXUNIX上的實戰詳解》集中討論19, 還是繼續大大大前天的話題——對Oracle效能統計中的資料解釋

從前面得到的統計資料，我們可以看出這樣一個問題：當大量資料擺在你面前，很多資料表現出模稜二可的狀態，你如何從中找到能反映出問題的資料，並確保其是對的？沒有別的分方法，只有再去印證其他資料或統計，交叉檢查、互相印證正確性。

 

下面是一些常見誤解和易被想當然的若干點：

 

關於命中率的想當然：

很多時候，命中率可以給我們一些提示，並用來表明問題，例如，資料快取記憶體命中率、SQL軟解析比率等。但他們能夠確定問題所在位置嗎？不能貿然的下結論說這裡就是瓶頸！正確的態度是：這是一個提示，可以用來佐證“某個問題”是瓶頸。

 

帶有時間資訊的等待事件：

 

當我們將Oracle的TIMED_STATISTICS 引數值設定為true（這就是預設值）時，等待事件的統計值中將包含時間資訊。我們知道，統計資料的絕對值是沒有意義的，我們比較的是可對比時間段內的不同或者增量。很多時候這個統計沒有意義。例如，經過統計我們發現某一個等待事件的值相比其他等待事件是很高的，那麼，瓶頸就是它嗎？不一定！這個需要分為二種情況。其一，如果這個等待事件的時間統計累積值佔據了整個DB time的大多數，則他很有可能就是瓶頸所在。但是，如果該等待事件累積時間很高，但和整體DB time相比，卻只佔了其中很小部分，則該等待事件可能說明不了任何問題。

 

特別說明：如果初始化引數STATISTICS_LEVEL 設定為TYPICAL（預設值）或者ALL ，則時間統計自動開啟。如果STATISTICS_LEVEL 設定為BASIC ，則我們必須手工將TIMED_STATISTICS設定為TRUE ，才能實現包含時間統計資料的收集。

 

另外，如果我們明確設定了DB_CACHE_ADVICE、TIMED_STATISTICS或者TIMED_OS_STATISTICS ，則我們為STATISTICS_LEVEL設定的引數值失效。

Oracle統計資料能否反映事實？

 

當檢視統計資料時，我們要考慮統計資料的真實度，也就是說，該資料能否反映這個系統真正的問題。例如，當統計資料說明系統每秒處理10個事務時，我們不說說這個系統載荷很輕。為什麼呢？因為統計期間可能發生的半夜，這的時間段根本就沒有業務產生。反之，我們看到資料快取命中率很低，也許我們也不能說應用系統記憶體使用有問題。原因也很簡單：統計期間，可能系統剛開機不久。

 

那什麼資料才是真實的？這裡有一個同樣模糊的回答：經過你綜合考慮過的統計資料是真實的！

 

沒有時間統計等待事件的可用性

 

如果系統TIMED_STATISTICS 引數設定為false，也就是不進行時間統計（在生產系統上這是普遍存在的設定，因為設定該引數為真則本身就會給系統帶來負的效能影響），那麼含有時間資訊的等待事件的時間統計不可用。這時，我們只能簡單地對等待事件發生數量進行排序，掌握那個等待事件發生次數最多、次多、再次多…。發生次數最多的等待事件是主要瓶頸嗎？也許是，是因為它發生的次數很多。不是主要瓶頸嗎？有可能，因為等待次數最多的等待時間未必最長。所以，在可能的情況下，啟用時間統計（設定TIMED_STATISTICS 引數為true）很有幫助。在Oracle中，該引數預設為true。

 

空閒等待事件

 

Oracle使用等待事件來表明一個Oracle伺服器程式是否是空閒的。一般而言，這些等待對於效能調整問題沒什麼用處。

 

彙總過的統計資料

 

在我們使用“率”這個增強型統計的時候，例如，資料快取命中率的時候，要注意經過彙總的資料可能帶來誤解。什麼是“率”，分子分母間除的操作。我們獲取某一個“率”，例如：50%，它說明了什麼呢？可能是50/100，也可能是50000/100000。這完全是二個數量級之間的差異。因此，同樣的比率，解讀確是不同的。一個可能是：我需要查詢100個資料塊，其中50個可以來源於資料快取，命中率50%。另一個解釋是：我要訪問100000個資料塊（100000*8K≈800M），其中50000個塊在資料快取中（≈400M）！顯然，就第一種解讀來說，50%的命中率是不需要調整的，但就第二種解讀來說，50%命中率可能不能接受，要麼去改SQL語句（甚至連帶進行應用業務上的調整），要麼去改索引結構，優化SQL執行路徑。總之，要有所為了。

 

因此，就統計資料而言，不應該侷限在某個或某組統計資料中洋洋自得，並據此認為已經找到問題根源，實際情況是：可能還有距離！

 

未完，待續， 文平

參見Oracle聯機文件中的“效能”那本書，以及 http://www.usedb.cn/

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