<資料庫正常執行，突然變慢的解決思路>

資料庫正常執行，突然變慢的解決思路：

1、檢視資料庫版本（select * from v$version）

2、檢視作業系統的程序（top，ps -ef）

3、檢視作業系統的IO情況（sar 1 10）

4、製作awr報表，檢視報告

在報告中 ：

Event	Waits	%Time -outs	Total Wait Time (s)	Avg wait (ms)	Waits /txn
control file parallel write	500	0.00	11	23	10.42
log file parallel write	107	0.00	1	8	2.23
log file sync	45	0.00	0	8	0.94
db file sequential read	182	0.00	0	2	3.79
SQL*Net break/reset to client	6	0.00	0	17	0.13
os thread startup	1	0.00	0	28	0.02
db file scattered read	5	0.00	0	2	0.10
SQL*Net more data from client	39	0.00	0	0	0.81
control file sequential read	1,142	0.00	0	0	23.79
SQL*Net message to client	7,743	0.00	0	0	161.31
SQL*Net more data to client	346	0.00	0	0	7.21
latch: shared pool	1	0.00	0	1	0.02
LGWR wait for redo copy	20	0.00	0	0	0.42
direct path read	89	0.00	0	0	1.85
rdbms ipc reply	3	0.00	0	0	0.06
direct path write	12	0.00	0	0	0.25
SQL*Net message from client	7,739	0.00	17,212	2224	161.23
Streams AQ: qmn slave idle wait	54	0.00	1,475	27322	1.13
Streams AQ: qmn coordinator idle wait	109	50.46	1,475	13536	2.27
virtual circuit status	50	100.00	1,458	29156	1.04
Streams AQ: waiting for time management or cleanup tasks	1	100.00	77	76683	0.02
jobq slave wait	20	100.00	59	2931	0.42

客戶端連線時間都是很長，很可以。我就是問下伺服器管理員，此伺服器的網路是否和平時網路一致。

伺服器管理員和我說這臺伺服器是遠端連線。遠端連線稍有延遲很正常。所以我做出了合理解釋。

       通過這個問題解決，感覺自己在這方面很欠缺，所以在網上找了些資料。

以下是轉載資料:

　　資料庫慢一般有三種情況

　　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 指令碼, 並在現象發生時及時按下回車鍵

　　一個例子

　　資料庫突然變慢

　　背景: 一個新應用上線後, 資料庫突然變慢

　　第一步, 調查新應用

　　據開發人員講新應用訪問的都是新建立的表, 表的資料量很小, 沒有複雜的SQL查詢.

　　查詢 v$sqlarea 分別按照disk_reads / buffer_gets / executions 排序, TOP SQL 中沒有新應用的SQL. 排除新應用資料庫訪問照成的效能問題.

　　第二步, 察看資料庫log/ OS log

　　資料庫log中可以看到大量的ORA-7445錯誤, 以及大量的dump檔案. 分析dump檔案(時間久了,沒有dump檔案可參考, 具體細節沒法描述下來. ), 發現是新應用通過dblink訪問remote DB時生成的dump檔案, 應用開發人說沒法修改, Oracle也沒有相應的patch解決.

　　OS log中沒有錯誤資訊

　　第三步, 察看statspack report

　　從wait events中看到,Top event是“buffer busy waits” “db file parallel write” 等於IO相關的等待事件.

　　從buffer busy waits 的統計資訊來看, 是等待data block.

　　還有些physical reads等資訊與從前比沒有太多的異常.

　　Tablespace 的IO reads/writes也沒有異常, 但是wait明顯增加.

　　初步確定是IO問題.

　　第四步, 察看OS的資訊

相關推薦