網(wǎng)友解決數(shù)據(jù)庫(kù)變慢了類問(wèn)題的一般思路

文章來(lái)源：泛普軟件

我們?cè)谌粘５墓芾碇? 經(jīng)常會(huì)碰到客戶或開(kāi)發(fā)人員反應(yīng)速度變慢了. 這一類問(wèn)題常使初級(jí)DBA摸不著頭腦, 還不如數(shù)據(jù)庫(kù)直接報(bào)出某個(gè)錯(cuò)誤, 更直接了當(dāng). 下面簡(jiǎn)單描述一下, 解決這類問(wèn)題時(shí)的一般思路。

如果有人反應(yīng)速度變慢了, 最有可能影響速度的, 無(wú)外乎CPU, 內(nèi)存和I/O. 在操作系統(tǒng)下,我們可以先使用top命令, 查看一下CPU的占用情況. 在top的輸出結(jié)果中, 特別要注意第一行中的load average, CPU的負(fù)載情況. 如果這里顯示的數(shù)字大于CPU數(shù), 說(shuō)明CPU的負(fù)載有點(diǎn)高了. 再結(jié)合第三行一起看, 如果第三行中, CPU的空閑比例為0, 就說(shuō)明CPU存在爭(zhēng)用. 正常情況下, CPU應(yīng)該有一定的空閑才好. 如果這里顯示空閑為0, 爭(zhēng)用CPU的不一定都是Oracle的進(jìn)程. top的下面顯示的進(jìn)程的列表, 只需看一下占用CPU高的進(jìn)程是否是Oracle相關(guān)的進(jìn)程, 即可確認(rèn)此點(diǎn). 如果運(yùn)氣好, 或許可以直接發(fā)現(xiàn)某個(gè)進(jìn)程占用了過(guò)多的CPU. 如果將問(wèn)題定位到了某個(gè)進(jìn)程, 對(duì)進(jìn)一步解決問(wèn)題, 有很大的幫助. 但, 大多數(shù)時(shí)候, CPU的爭(zhēng)用已經(jīng)很高了, 但是在進(jìn)程列表中, 發(fā)現(xiàn)不了某些進(jìn)程占用過(guò)高的CPU. 這時(shí)要定位問(wèn)題, 可能要復(fù)雜一些. 我們可以進(jìn)入Oracle, 查看v$sqlarea或等待事件.

在v$sqlarea視圖中, Elapsed_time和CPU_time對(duì)了解每條SQL聲明的CPU占用情況最有幫助. 其中CPU_TIME是執(zhí)行SQL聲明所耗用的CPU時(shí)間. Elapsed_time除實(shí)際耗用的CPU時(shí)間外, 還要加上等待時(shí)間. 如果觀察V$SQLAREA沒(méi)有發(fā)現(xiàn)特別耗用CPU的SQL聲明. 可以在Statspace報(bào)告中對(duì)比一下正常時(shí)期的數(shù)據(jù), 觀察一下看有沒(méi)有某條語(yǔ)句的CPU時(shí)間, 執(zhí)行次數(shù)出現(xiàn)異常的變化. 有時(shí), 或許有些SQL的CPU占用不高, 但執(zhí)行次數(shù)卻非常的高, 這也可能會(huì)成為造成CPU爭(zhēng)用的原兇. 解決問(wèn)題時(shí), 將問(wèn)題定位的某個(gè)確定的地方, 是解決問(wèn)題的第一步. 這里, 如果可以將問(wèn)題定位到某條確定的SQL, 距真正的解決問(wèn)題, 就向前邁了一大步. 關(guān)于SQL聲明的調(diào)優(yōu), 可是個(gè)大問(wèn)題, 這篇短短的文章很難表述清楚, 我們到以后的系列實(shí)驗(yàn)中再討論.

o+W*i"u#{;m6P^Kw0 在V$sqlarea視圖中,除了上面說(shuō)過(guò)的Elapsed_time力CPU_time兩列外, 在了解某條SQL聲明的情況時(shí),下面的這些列也很有用:

"U7H x&?-Q4G#^:wAc0 disk_reads:物理讀
f4e|"Q7@6E*^6