熟悉Oracle數據庫的DBA肯定用過AWR報告和ASH報告。AWR報告是很多DBA分析Oracle數據庫性能問題的利器。而對于ASH報告的使用則稍微陌生一點。事實上ASH報告包含的技術細節也是不夠的，ASH的明細數據更有分析價值。

圖片

Oracle的AWR的 LOAD PROFILE 可以十分明確地反映出數據庫的負載情況，目前絕大多數國產數據庫都提供類似Oracle AWR這樣的負載報告，數據庫負載情況是分析數據庫性能問題的關鍵。很多問題從歷史負載的比對就可以得到結論。命中率指標也是反映出數據庫性能的十分明確的指標，一些因為數據庫配置有問題導致的性能問題，很可能會反映在命中率上。幸運的是，國產數據庫的AWR報告里這方面的數據也比較完善。

圖片

等待事件是分析Oracle問題的最有價值的數據，如果發現明顯某種等待事件影響了性能，那么在MOS上豐富的資料庫中搜索一番，可能就能找到答案了。不幸的是，國產數據庫缺少MOS這樣的知識庫，因此分析等待事件的能力偏弱一些，不過有經驗的DBA還是可以從中分析出一些問題。比如上面的等待事件中，WAL寫入鎖占了大部分等待時間，優化WAL子系統性能應該能夠改善性能。

圖片

上圖是電科金倉數據庫的時間模型。時間模型是分析數據庫總體性能問題中十分有價值的數據，不過這些數據的解讀因為需要比較專業的數據庫知識而往往被忽視了。通過時間模型，我們可以看出數據庫在哪些地方消耗了更多的時間，一般與做總體優化。如果某數據庫的時間模型數據是準確的，那么可以做很多有價值的分析，定期采集數據庫的時間模型，并保存起來，當某些故障發生時進行標注，積累多了，就可以構建分析與預測模型了。

“AWR”報告比較適合于宏觀分析，那么ASH數據在微觀分析方面很有價值。比如我們從“AWR”報告中看出行鎖等待是引發性能問題的關鍵。那么我們就需要去定位為什么行鎖等待會那么嚴重。這時候AWR報告不一定能發揮作用了。有可能行鎖等待只持續了幾分鐘，而AWR報告是1小時采樣的，無法通過細微的分析最終定位問題的根因。另外鎖等待或阻塞類的問題，在ASH數據里是能夠明確查到阻塞者的。找出阻塞者，分析阻塞者在做什么，在等待什么，往往是定位問題根因的關鍵。

ASH數據還可以用來分析某些SQL語句并發執行的情況，會話的變化情況（會話數量、會話分布情況、活躍會話數量、異常會話數量、阻塞會話數量等的變化），結合服務器資源變化的趨勢，可以獲得十分有價值的分析結果。一般的分析方法如下：

圖片

今天因為時間關系，我就不展開這張圖的解釋了，明天我會寫一個最近遇到的這方面的案例，到時候再來分析這種圖吧。ASH數據要能夠定位根因就必須是十分豐富的。數據甚至比會話視圖里的數據還要豐富。Oracle的ASH數據就是如此的，在數據中還包含了會話兩次被采樣之間的各種統計數據的變化，比如物理讀的次數、總量等。這些數據對于定位根因十分關鍵。

圖片

幸運的是越來越多的國產數據庫目前已經開始支持活躍會話數據的采樣與保存，讓我們獲得了這個分析微觀問題的關鍵數據。AWR做宏觀分析，找出大體的分析方向；然后使用ASH數據做微觀分析，通過阻塞鏈分析，執行SQL情況的分析等實現更為精準的定位，這樣的組合分析是定位性能問題根因的有效手段。

不過國產數據庫的ASH數據與Oracle相比還有很大的差距，上圖是電科金倉的ASH數據，其豐富程度與Oracle還有一定的差距。實際上Oracle是把SESSION STATE OBJECT中的所有數據都做了合并，形成了比v$session更為豐富的數據。國產數據庫廠商也應該學習一下，ASH不應該是個擺設，而應該成為分析阻塞類根因的利器。