Oracle故障分析的幾點小結

這是學習筆記的第 1851篇文章

今天分析了幾類Oracle問題，也算是深有感觸。

第一個是協助老同學排查一個性能故障，根據反饋每周的周日跑批量任務前端都會卡住，沒有響應，之前拿到AWR分析了下，做了一些系統層面的優化，但是根據后續的跟進，說還是有批量任務卡住的情況。常州數據恢復

AWR的部分信息如下：

這張圖的信息量非常大，如果分析不夠深入，很可能會漏掉一些關鍵的信息。當然僅僅靠一個報告把問題的前因后果都腦補出來也是不現實的，我等下會給出幾個建議。

通過這個報告可以明確的看到這是一個小機環境的數據庫環境，DB time指標很高，有近80倍。

而通過profile的信息可以明確的看到，每秒的redo有5M多，值得一提的是每個事物的redo量是11M左右，可以換算為每2秒是一個事務redo的寫入量。一個事務11M的redo從哪里來呢，可以看下Executes和 User calls來輔助，可以得到一個相對粗略的估算，那就是一個事務包含大約1300個左右個SQL。按照這個比例，這個事務的粒度確實有些太大了。

而另外一個指標是Rollbacks的指標看起來是0.3，而相比于Transactions為0.5，這個0.3就有點高了，也就意味著事務回滾率是很高的。

只有為什么等待這么高，我們可以看下相關的SQL

可以明顯看到問題，那就是很多insert SQL的執行次數為0，是什么情況會導致insert阻塞呢，本身insert操作應該是最直白的一類DML了，是最不應該被阻塞的了。

對于上面的信息我們其實得到的是一個模糊的印象，最近怎么樣，1點的時候性能差，那么2:00呢。最近的性能怎么樣，其實我們是應該要了解的。

怎么得到這些信息呢，抱歉Oracle原生似乎沒有提供這些信息。

我們可以借助于自定義的腳本。

腳本可以參考之前的開源項目:

https://github.com/jeanron100/dbm_lite/

腳本showsnap.sh的輸出如下。可以看到一個性能的變化情況，對于分析問題的方向是很重要的。

我們可以通過這個腳本來得到redo的切換情況，腳本是showarchrate.sh

通過這個就可以清晰的看到最近一段時間的性能變化，redo的切換是一個非常有效的指標，通過它來反應數據庫的負載也是一種比較好的方式。

而對于問題的分析如何深入呢，我守在了電腦前，做了認真的分析，對于一個數據庫，產生了上千連接的情況下，如何去定位性能瓶頸呢，最好的一種方式就是ASH，但是顯然ASH有一個問題，那就是少了很多會話層面的明細信息，讓我們知道問題，但是得到的信息還是有限，所以我們還需要另外一個腳本getash.sh來實時得到活躍會話的數據。

比如通過這個腳本的輸出我們清晰的定位到現在在執行哪些SQL,是否有潛在的阻塞和鎖的情況，都是一目了然。