問題描述:
今天上午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解析和全表掃描。