<數(shù)據(jù)庫正常運(yùn)行，突然變慢的解決思路>

數(shù)據(jù)庫正常運(yùn)行，突然變慢的解決思路：

1、查看數(shù)據(jù)庫版本（select * from v$version）

2、查看操作系統(tǒng)的進(jìn)程（top，ps -ef）

3、查看操作系統(tǒng)的IO情況（sar 1 10）

4、制作awr報(bào)表，查看報(bào)告

在報(bào)告中 ：

EventWaits%Time -outsTotal 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

客戶端連接時(shí)間都是很長，很可以。我就是問下服務(wù)器管理員，此服務(wù)器的網(wǎng)絡(luò)是否和平時(shí)網(wǎng)絡(luò)一致。

服務(wù)器管理員和我說這臺服務(wù)器是遠(yuǎn)程連接。遠(yuǎn)程連接稍有延遲很正常。所以我做出了合理解釋。

?????? 通過這個(gè)問題解決，感覺自己在這方面很欠缺，所以在網(wǎng)上找了些資料。

以下是轉(zhuǎn)載資料:

　　數(shù)據(jù)庫慢一般有三種情況

　　1。逐漸變慢

　　2。突然變慢

　　3。不定時(shí)變慢

　　第一種情況 “逐漸變慢”，要建立一個(gè)長期的監(jiān)控機(jī)制。比如，寫個(gè)shell腳本每天的忙時(shí)(通常9~10 etc.)定時(shí)收集os,network,db的信息， 每個(gè)星期出report對收集到的信息進(jìn)行分析。這些數(shù)據(jù)的積累，可以決定后期的優(yōu)化決策，并且可以是DBA說服manager采用自己決策的重要數(shù)據(jù)。DBA的價(jià)值，就在每個(gè)星期的report中體現(xiàn)。

　　第二種情況 “突然變慢”，也是最容易解決的。先從業(yè)務(wù)的角度看是DB的使用跟以前有何不同，然后做進(jìn)一步判斷。硬件/網(wǎng)絡(luò)故障通常也會引起DB性能的突然下降。

　　第一步: 察看DB/OS/NETWORK的系統(tǒng)log, 排除硬件/網(wǎng)絡(luò)問題

　　第二步：察看數(shù)據(jù)庫的等待事件，根據(jù)等待事件來判斷可能出問題的環(huán)節(jié)。如果, 沒有等待事件, 可以排除數(shù)據(jù)庫的問題. 如果有等待時(shí)間, 根據(jù)不同的等待事件, 來找引起這些事件的根源.

　　比如latch free等跟SQL parse有關(guān)系的等待事件，OS的表現(xiàn)是CPU 的占用率高

　　db file scattered read等跟SQL disk read有關(guān)系的等待時(shí)間， OS的表現(xiàn)是iostat可以看到磁盤讀寫量增加

　　第三步: 察看os的信息, CPU/IO/MEMORY等.

　　a. Cpu 的占用率

　　CPU占用率與數(shù)據(jù)庫性能不成反比. CPU占用率高, 不能說明數(shù)據(jù)庫性能慢. 通常情況, 一個(gè)優(yōu)化很好, 而且業(yè)務(wù)量確實(shí)很大的數(shù)據(jù)庫, CPU的占用率都會高, 而且會平均分布在每個(gè)進(jìn)程上. 反過來, CPU的占用率都會高也不代表數(shù)據(jù)庫性能就好, 要結(jié)合數(shù)據(jù)庫的等待事件來判斷CPU占用率高是否合理.

　　如果某個(gè)進(jìn)程的cpu占用高, 肯定是這個(gè)進(jìn)程有問題. 如果,不是oracle的進(jìn)程, 可以讓application察看是否程序有死循環(huán)等漏洞. 如果,是oracle的進(jìn)程, 可以根據(jù)pid查找oracle數(shù)據(jù)字典看看這個(gè)進(jìn)程的發(fā)起程序, 正在執(zhí)行的sql語句, 以及等待事件. 然后, 不同情況使用不同的方法來解決.

　　b. IO

　　排除硬件的IO問題, 數(shù)據(jù)庫突然變慢, 一般來說, 都是一個(gè)或幾個(gè)SQL語句引起的.

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

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

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

　　c. Memory

　　第二種情況與memory的關(guān)系比較小, 只要SGA區(qū)配置合理沒有變化, 一般來說, 只要不是Application Memory leak, 不會引起突然變慢的現(xiàn)象.

　　第三種情況 “不定時(shí)變慢”, 是最難解決的. 現(xiàn)場出現(xiàn)的問題原因也是五花八門千奇百怪, 最重要的是, 出現(xiàn)慢的現(xiàn)象時(shí), 以最快的速度抓取到最多的信息以供分析. 先寫好抓取數(shù)據(jù)的shell 腳本, 并在現(xiàn)象發(fā)生時(shí)及時(shí)按下回車鍵

　　一個(gè)例子

　　數(shù)據(jù)庫突然變慢

　　背景: 一個(gè)新應(yīng)用上線后, 數(shù)據(jù)庫突然變慢

　　第一步, 調(diào)查新應(yīng)用

　　據(jù)開發(fā)人員講新應(yīng)用訪問的都是新建立的表, 表的數(shù)據(jù)量很小, 沒有復(fù)雜的SQL查詢.

　　查詢 v$sqlarea 分別按照disk_reads / buffer_gets / executions 排序, TOP SQL 中沒有新應(yīng)用的SQL. 排除新應(yīng)用數(shù)據(jù)庫訪問照成的性能問題.

　　第二步, 察看數(shù)據(jù)庫log/ OS log

　　數(shù)據(jù)庫log中可以看到大量的ORA-7445錯(cuò)誤, 以及大量的dump文件. 分析dump文件(時(shí)間久了,沒有dump文件可參考, 具體細(xì)節(jié)沒法描述下來. ), 發(fā)現(xiàn)是新應(yīng)用通過dblink訪問remote DB時(shí)生成的dump文件, 應(yīng)用開發(fā)人說沒法修改, Oracle也沒有相應(yīng)的patch解決.

　　OS log中沒有錯(cuò)誤信息

　　第三步, 察看statspack report

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

　　從buffer busy waits 的統(tǒng)計(jì)信息來看, 是等待data block.

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

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

　　初步確定是IO問題.

　　第四步, 察看OS的信息

　　1. top 命令(輸出為實(shí)驗(yàn)室數(shù)據(jù)，僅作格式參考)

　　load averages: 0.05, 0.10, 0.09 10:18:32

　　307 processes: 304 sleeping, 1 zombie, 1 stopped, 1 on cpu

　　CPU states: 96.0% idle, 0.3% user, 2.6% kernel, 1.1% iowait, 0.0% swap

　　Memory: 4096M real, 2660M free, 1396M swap in use, 3013M swap free

　　PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND

　　11928 a21562 1 0 0 3008K 2496K cpu/1 0:02 1.12% top

　　14965 mpgj76 4 59 0 10M 3696K sleep 3:09 0.18% view_server

　　當(dāng)時(shí)現(xiàn)場數(shù)據(jù)顯示：iowait 值與以前相比大很多， 沒有異常進(jìn)程

　　2. sar –d (輸出為實(shí)驗(yàn)室數(shù)據(jù)，僅作格式參考)

　　SunOS sc19 5.7 Generic_106541-42 sun4u 03/20/08

　　00:00:00 device %busy avque r+w/s blks/s avwait avserv

　　sd410 17 0.4 50 1628 0.1 7.1

　　sd410,a 0 0.0 0 0 0.0 0.0

　　sd410,b 0 0.0 0 0 0.0 0.0

　　sd410,c 0 0.0 0 0 0.0 0.0

　　sd410,g 17 0.4 50 1628 0.1 7.1

　　當(dāng)時(shí)現(xiàn)場數(shù)據(jù)顯示，放數(shù)據(jù)文件的設(shè)備 avwait, avque, blks/s值偏大

　　第五步, 察看數(shù)據(jù)庫的等待事件

　　一個(gè)大業(yè)務(wù)量的數(shù)據(jù)庫如果性能不好的話, 一般來說都會有大量的等待事件, 上百個(gè)等待事件很常見, 我通常會按照EVENT進(jìn)行g(shù)roup.

　　Select count(*), event from v$session_wait where event not in ('smon timer','pmon timer','rdbms ipc message','SQL*Net message from client') group by event order by 1 desc;

　　輸出結(jié)果顯示最多的等待事件是buffer busy waits。

　　進(jìn)一步分析，找出等待的原因

　　Select count(*), p1, p2, p3 from v$session_wait where event = ‘buffer busy waits’ group by p1,p2,p3;

　　在buffer busy waits等待事件中

　　P1 = file#

　　P2 = block#

　　P3 = id ( 此id對應(yīng)為等待的原因)

　　按照p1,p2,p3 group是為了明確buffer busy waits的等待集中在哪些對象上。

　　Metalink對buffer busy waits等待事件的描述有如下一段話：

　　“If P3 shows that the "buffer busy wait" is waiting for a block read to complete then the blocking session is likely to be waiting on an IO wait (eg: "db file sequential read" or "db file scattered read" for the same file# and block#.”

　　輸出結(jié)果顯示，等待分布在多個(gè)不同的對象上，等待原因?yàn)?“waiting for a block read to complete”，進(jìn)一步分析為IO的問題。

　　如果，buffer busy waits等待集中在某個(gè)對象上，說明有hot block, 通過重新rebuild這個(gè)對象增加freelist來解決,RAC環(huán)境增加freelist group.

　　通過以下SQL可以找到具體的object.

　　Select owner, segment_name, segment_type from dba_extents where file_id=P1 and P2 between block_id and block_id+blocks;

　　P1,P2是上面v$session_wait查出的具體的值

　　第六步, 明確原因，找出解決步驟

　　分析：

　　1。磁盤的IO流量增加

　　2。磁盤的IO等待增加

　　3。DB的IO流量沒有增加

　　4。DB的IO等待增加

　　由1，2，3，4可以推出，有數(shù)據(jù)庫以外的IO訪問磁盤。

　　察看磁盤配置，該VG只存放了數(shù)據(jù)庫數(shù)據(jù)文件和數(shù)據(jù)庫系統(tǒng)文件。排除數(shù)據(jù)文件，產(chǎn)生IO的是數(shù)據(jù)庫系統(tǒng)文件。

　　數(shù)據(jù)庫系統(tǒng)文件一般來說不會產(chǎn)生IO, 有IO讀寫的地方只有l(wèi)og和dump文件。

　　結(jié)論：ora-7445產(chǎn)生的大量core dump文件堵塞IO

　　解決辦法：

　　1，消除ora-7445. (應(yīng)用不改的情況下，無法解決)

　　2, 把dump目錄指向別的VG

　　3, 讓oracle盡量少的去寫core dump文件

　　background_core_dump = partial

　　shadow_core_dump = partial

總結(jié)

以上是生活随笔為你收集整理的数据库正常运行，突然变慢的解决思路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。