問題描述:

今天上午10點多，公司網路斷了一會，過了大約十來分鐘，網工處理好了，可資料庫這下子可撐不住了，開啟linux top查看了一下CPU百分百了，這可能是因為緩衝在客戶端的資料一下子全傳上來了導致資料庫壓力過大，可以前沒有出現過這種問題，於是進行了分析和處理，以下為處理過程：

問題分析：

一般cpu佔用效高都是排序、sql解析和全表掃描，這裡首先需要找出佔用cpu最高的sql，然後檢視他的執行計劃，比如：看執行計劃是走索引還是全表掃描（剛開始檢視top發現佔用同樣多的CPU的程序很多，還以為是oracle 的bug, 後來發現不是）。

處理過程：

1, 根據作業系統程序查詢Oracle資料庫中佔用最多CPU的SQL

使用Linux系統 "top命令->P "查出佔用cpu最高的程序PID

操作如下：在sqlplus中執行如下sql:
SQL>

SELECT
sql_text
FROM v$sqltext a
WHERE (a.hash_value, a.address) IN
(SELECT DECODE(sql_hash_value, 0, prev_hash_value, sql_hash_value),
DECODE(sql_hash_value, 0, prev_sql_addr, sql_address)
FROM v$session b
WHERE b.paddr =
(SELECT addr FROM v$process c WHERE c.spid = '&pid'))
ORDER BY piece ASC

其中&pid 是使用top 檢視系統中程序佔用CPU極高的PID
找到SQL語句進行相應的調整優化

2，分析找到的sql語句，如檢視sql執行計劃。

總結：

這裡的問題是查詢的where 條件欄位沒有在索引裡面，導致查詢慢。經過重建並增加相關欄位到索引解決，但有點疑惑的是原來庫上查詢語句裡where條件欄位也沒有在索引裡面（新庫是使用expdp匯出再匯入到新庫的），查詢還正常，CPU也不高，oracle資料庫真是博大精深，好多問題還有待研究。

另外複合索引一定要匹配查詢的where條件，不然oracle不會走引索。

附：一般cpu佔用效高都是排序、sql解析和全表掃描。

=============================================================================================

版權所有，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任! 謝謝合作！

QQ:[email protected]
Sina:weibo.com/kaijunfeng
Yahoo:[email protected]