解決資料庫慢的方法論

資料庫的performance是一個長期的監控過程，不能頭疼醫頭，腳疼醫腳。

 

資料庫慢一般有三種情況

1。逐漸變慢

2。突然變慢

3。不定時變慢

 

 

第一種情況 “逐漸變慢”，要建立一個長期的監控機制。比如，寫個shell指令碼每天的忙時（通常9~10 etc.)定時收集os,network,db的資訊， 每個星期出report對收集到的資訊進行分析。 這些資料的積累，可以決定後期的優化決策，並且可以是DBA說服manager採用自己決策的重要資料。DBA的價值，就在每個星期的report中體現。

 

第二種情況 “突然變慢”，也是最容易解決的。先從業務的角度看是DB的使用跟以前有何不同，然後做進一步判斷。硬體/網路故障通常也會引起DB效能的突然下降。

 

第一步:  察看DB/OS/NETWORK的系統log, 排除硬體/網路問題

 

第二步：察看資料庫的等待事件，根據等待事件來判斷可能出問題的環節。如果, 沒有等待事件, 可以排除資料庫的問題. 如果有等待時間, 根據不同的等待事件, 來找引起這些事件的根源.

比如latch free等跟SQL parse有關係的等待事件，OS的表現是CPU 的佔用率高

db file scattered read等跟SQL disk read有關係的等待時間， OS的表現是iostat可以看到磁碟讀寫量增加

 

第三步: 察看os的資訊, CPU/IO/MEMORY等.

a.  Cpu 的佔用率

CPU佔用率與資料庫效能不成反比. CPU佔用率高, 不能說明資料庫效能慢.  通常情況, 一個優化很好, 而且業務量確實很大的資料庫, CPU的佔用率都會高, 而且會平均分佈在每個程式上. 反過來, CPU的佔用率都會高也不代表資料庫效能就好, 要結合資料庫的等待事件來判斷CPU佔用率高是否合理.

如果某個程式的cpu佔用高, 肯定是這個程式有問題. 如果,不是oracle的程式, 可以讓application察看是否程式有死迴圈等漏洞. 如果,是oracle的程式, 可以根據pid查詢oracle資料字典看看這個程式的發起程式, 正在執行的sql語句, 以及等待事件. 然後, 不同情況使用不同的方法來解決.

 

b. IO

排除硬體的IO問題, 資料庫突然變慢, 一般來說, 都是一個或幾個SQL語句引起的.

如果IO很頻繁, 可以通過優化disk reads高的TOP SQL來解決. 當然這也是解決IO問題的最笨也是最有效的辦法.

OS以及儲存的配置也是影響IO的一個重要的原因.

比如, 最常見的HP-unix下非同步IO的問題, 如果DBA GROUP沒有MLOCK的許可權, ORACLE是不使用AIO的. 偏偏OS與DB的兩方的admin如果配合不夠好地話, 這個配置就很容易給漏掉了.

 

c. Memory

第二種情況與memory的關係比較小, 只要SGA區配置合理沒有變化, 一般來說, 只要不是Application Memory leak, 不會引起突然變慢的現象.

 

第三種情況 “不定時變慢”, 是最難解決的. 現場出現的問題原因也是五花八門千奇百怪, 最重要的是, 出現慢的現象時, 以最快的速度抓取到最多的資訊以供分析. 先寫好抓取資料的shell 指令碼, 並在現象發生時及時按下Enter鍵 :)

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