问题描述:
今天上午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解析和全表扫描。