两种可能：
1: A Background (instance) process
2: An Oracle (user) process #此种可能最大。
处理：
1.查看每个Session的CPU利用情况：
select ss.sid,se.command,ss.value CPU ,se.username,se.program
from v$sesstat ss, v$session se
where ss.statistic# in
(select statistic#
from v$statname
where name = 'CPU used by this session')
and se.sid=ss.sid
and ss.sid>6
order by ss.sid
2.比较一下哪个session的CPU使用时间最多，然后查看该Session的具体情况：
select s.sid, s.event, w.wait_time, w.seq#, q.sql_text
from v$session_wait w, v$session s, v$process p, v$sqlarea q
where s.paddr=p.addr and
s.sid=&p and
s.sql_address=q.address
---------------------------------------------------------------------------------------------
Oracle进程导致CPU 100%解决步骤
1:检查系统
sar -u 5 5
2: 看谁在用CPU
topas
ps -ef |grep ora #检查第四列，C的大小（unit，100 per cpu）
3:检查CPU数量
/usr/sbin/bindprocessor -q
lsattr El proc0
4:两种可能：
1: A Background (instance) process
2: An oracle (user) process ＃此种可能最大。
5: 如果是用户进程：那么高CPU的主要原因有：
Large Queries, Procedure compilation or execution,
Space management and Sorting
5.1 查看每个Session的CPU利用情况：
select ss.sid,se.command,ss.value CPU ,se.username,se.program
from v$sesstat ss, v$session se
where ss.statistiC# in
(select statistic#
from v$statname
where name = ''CPU used by this session'')
and se.sid=ss.sid
and ss.sid>6
order by ss.sid
使用时间最多，然后查看该Session的具体情况：
5.2: 比较上述Session
比较一下哪个session的CPU
select s.sid, event, wait_time, w.seq#, q.sql_text
from v$session_wait w, v$session s, v$process p, v$sqlarea q
where s.paddr=p.addr and
s.sid=&p and
s.sql_address=q.address;
5.3:查看
得到上述信息后，查看相应操作是否有hash joins 和 full table scans。如果有hash joins 和 full table scans那么必须创建相应的Index或者检查Index是否有效。
另外必须检查是否有并行的查询存在和同一时刻有多个用户在执行相同的SQL语句，如果有必须关闭并行的查询和任何类型的并行提示(hints);如果查询使用intermedia数据，那么为了减少总的Index大小，必须限制使用Intermedia的Worldlist。（try restricting the wordlist that intermedia uses to help reduce the total indexsize）。
6:注意事项
上述方案只能根据已经运行完成的操作，对于正在执行的长时间操作只能等操作完成后才能检测得到。因此我们可以通过另外一个很好的工具来检测正在运行的长时间操作语句。v$session_longops,这个视图显示那些操作正在被运行，或者已经完成。每个process完成后会刷新本视图的信息。
7:怎样寻找集中使用CPU的Process：
很多时候会发现有N个Process在平均分享着CPU的利用率，这种情况唯一的可能性就是这些Process在执行着相同的Package或者Query.
这种情况：建议通过statspack,在CPU高利用率额时候运行几个快照，然后根据这些快照检查Statspack报告，检查报告中最TOP的Query。然后使用 sql_trace and tkprof 工具去跟踪一下。
同时检查buffer cache 的命中率是否大雨95％。
同时在报告中还需要检查一下table scans (long tables)，看是否在报告生成期间有存在全表扫描。
8:参数
另外还有一些不是特别重要的，但是也必须关心检查的参数可能消耗CPU。
parallel query 并行查询：
并行查询最好用于数据仓库的环境下，那种情况任何时候只有几个用户在同时使用。在一个联机事务处理环境中，当同时许多用户去并行查询一个数据库的巨大表时候，会导致CPU的爆满。所以最好在数据库的级别关闭并行查询：设置参数如下：
parallel_min_server = 0 parallel_max_server = 0
parallel_automatic_tuning = false;
在配置上述参数后，如果SQL语句中使用的并行的提示，那么还是有可能会出现并行查询的情况，所以还需要继续监视相关的SQL语句，如果有可以直接去除提示。