網友解決數據庫變慢了類問題的一般思路

申請免費試用、咨詢電話：400-8352-114

我們在日常的管理中, 經常會碰到客戶或開發(fā)人員反應速度變慢了. 這一類問題常使初級DBA摸不著頭腦, 還不如數據庫直接報出某個錯誤, 更直接了當. 下面簡單描述一下, 解決這類問題時的一般思路。

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

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

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

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