❶ oraclecpu占用率高怎么处理
问题分析：
一般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数据库真是博大精深，好多问题还有待研究。
❷ oracle 4031会导致cpu100%吗
ORA-4031错误
1. ORA-4031错误的原因，一般是大量的hard parse导致了shared pool中的free list中产生大量的内存小碎片，当一个需要很大内存来进行hard parse的sql语句到来时，无法从free list中找到内存，即使进行内存的释放，还是不能找到符合的内存块。从而报ORA-4031错误。
2. ORA-4031错误的解决方法：
1）alter system flush shared_pool;将shared pool中的所有内存清空。该方法治标不治本。
2）共享SQL语句：规范SQL语句的书写；使用绑定变量；找到没有使用绑定变量的SQL：
select sql_fulltext from v$sql where executions=1 order by sql_text;
如果在结果中发现一系列仅仅字面值不同的SQL，则可以修改cursor_sharing参数：
alter system set cursor_sharing = 'force'; 来强制使用绑定变量。
3）使用shared pool中的保留区：
select request_misses from v$shared_pool_reserved;
如果结果大于0，则可以调大shared_pool_reserved的大小；
SQL> show parameter shared_pool
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
shared_pool_reserved_size big integer 4M
shared_pool_size big integer 0
alter system set shared_pool_reserved=xxM scope=both;
4）使用dbms_shared_pool.keep('对象名')将使用内存很大的对象keep在内存中：
先要执行：@?/rdbms/admin/dbmspool.sql
SQL> @?/rdbms/admin/dbmspool.sql
Package created.
Grant succeeded.
View created.
Package body created.
再查出需要keep的对象：
SQL> select owner,name,namespace,type,sharable_mem from v$db_object_cache where sharable_mem>10000
2 and (type='PACKAGE' or type='PACKAGE BODY' or type='FUNCTION' or type='PROCEDURE') and kept='NO';
OWNER NAME NAMESPACE TYPE SHARABLE_MEM
---------- ------------------------- ------------------ --------------- ------------
SYS DBMS_BACKUP_RESTORE TABLE/PROCEDURE PACKAGE 33215
SYSMAN EMD_COLLECTION BODY PACKAGE BODY 33233
SYS DBMS_SHARED_POOL BODY PACKAGE BODY 12644
SYS SYS$RAWTOANY TABLE/PROCEDURE FUNCTION 12640
SYSMAN EMD_MAINTENANCE TABLE/PROCEDURE PACKAGE 29030
SYSMAN EMD_MAINTENANCE BODY PACKAGE BODY 62930
SYSMAN MGMT_JOB_ENGINE BODY PACKAGE BODY 218914
SYSMAN EM_PING BODY PACKAGE BODY 29086
SYS DBMS_BACKUP_RESTORE BODY PACKAGE BODY 95519
SYSMAN EMD_LOADER TABLE/PROCEDURE PACKAGE 12641
SYSMAN EMD_LOADER BODY PACKAGE BODY 71861
SYS PRVT_HDM BODY PACKAGE BODY 43624
SYSMAN MGMT_JOB_ENGINE TABLE/PROCEDURE PACKAGE 24938
SYS STANDARD BODY PACKAGE BODY 24960
SYSMAN EM_SEVERITY_REPOS BODY PACKAGE BODY 33236
SYS PRVT_ADVISOR TABLE/PROCEDURE PACKAGE 12640
SYSMAN MGMT_GLOBAL TABLE/PROCEDURE PACKAGE 29902
SYS DBMS_STANDARD TABLE/PROCEDURE PACKAGE 24929
SYS DBMS_ADVISOR BODY PACKAGE BODY 25000
SYS PRVT_HDM TABLE/PROCEDURE PACKAGE 16732
SYS PRVT_ADVISOR BODY PACKAGE BODY 66780
SYS DBMS_RCVMAN TABLE/PROCEDURE PACKAGE 43295
SYS STANDARD TABLE/PROCEDURE PACKAGE 438648
SYS DBMS_RCVMAN BODY PACKAGE BODY 375759
24 rows selected.
5）增加shared_pool_size的大小：
SQL> select component,current_size from v$sga_dynamic_components;
COMPONENT CURRENT_SIZE
---------------------------------------------------------------- ------------
shared pool 75497472
large pool 4194304
java pool 4194304
streams pool 0
DEFAULT buffer cache 130023424
KEEP buffer cache 0
RECYCLE buffer cache 0
DEFAULT 2K buffer cache 0
DEFAULT 4K buffer cache 0
DEFAULT 8K buffer cache 0
DEFAULT 16K buffer cache 0
DEFAULT 32K buffer cache 0
ASM Buffer Cache 0
13 rows selected.
sga_max_size：SGA允许的最大值，修改必须重启；
sga_target：必须小于sga_max_size, 表示当前SGA的最大值；
alter system set shared_pool_size=xxM scope=both;
3. 使用V$SHARED_POOL_ADVICE来设置shared pool的大小
V$SHARED_POOL_ADVICE displays information about estimated parse time in the shared pool for different pool sizes. The sizes range from 10% of the current shared pool size or the amount of pinned library cache memory (whichever is higher) to 200% of the current shared pool size, in equal intervals. The value of the interval depends on the current size of the shared pool.
Column
Datatype
Description
SHARED_POOL_SIZE_FOR_ESTIMATE NUMBER Shared pool size for the estimate (in megabytes)
SHARED_POOL_SIZE_FACTOR NUMBER Size factor with respect to the current shared pool size
ESTD_LC_SIZE NUMBER Estimated memory in use by the library cache (in megabytes)
ESTD_LC_MEMORY_OBJECTS NUMBER Estimated number of library cache memory objects in the shared pool of the specified size
ESTD_LC_TIME_SAVED NUMBER Estimated elapsed parse time saved (in seconds), owing to library cache memory objects being found in a shared pool of the specified size. This is the time that would have been spent in reloading the required objects in the shared pool had they been aged out e to insufficient amount of available free memory.
ESTD_LC_TIME_SAVED_FACTOR NUMBER Estimated parse time saved factor with respect to the current shared pool size
ESTD_LC_LOAD_TIME NUMBER Estimated elapsed time (in seconds) for parsing in a shared pool of the specified size
ESTD_LC_LOAD_TIME_FACTOR NUMBER Estimated load time factor with respect to the current shared pool size
ESTD_LC_MEMORY_OBJECT_HITS NUMBER Estimated number of times a library cache memory object was found in a shared pool of the specified size
可以使用下面的SQL语句来预估shared pool的大小：
select 'Shared Pool' component,shared_pool_size_for_estimate estd_sp_size,estd_lc_time_saved_factor parse_time_factor,case when current_parse_time_elapsed_s + adjustment_s<0
then 0 else current_parse_time_elapsed_s + adjustment_s end response_time
from (
select shared_pool_size_for_estimate,shared_pool_size_factor,estd_lc_time_saved_factor,a.estd_lc_time_saved,e.value/100
current_parse_time_elapsed_s,c.estd_lc_time_saved - a.estd_lc_time_saved adjustment_s from v$shared_pool_advice a,
(select * from v$sysstat where name='parse time elapsed') e,
(select estd_lc_time_saved from v$shared_pool_advice where shared_pool_size_factor=1) c
);
COMPONENT ESTD_SP_SIZE PARSE_TIME_FACTOR RESPONSE_TIME
-------------- ----------------- ------------------------- -------------
Shared Pool 64 .9989 294.37
Shared Pool 72 1 257.37
Shared Pool 80 1.0009 226.37
Shared Pool 88 1.0016 201.37
Shared Pool 96 1.0022 181.37
Shared Pool 104 1.0027 166.37
Shared Pool 112 1.0029 156.37
Shared Pool 120 1.0032 149.37
Shared Pool 128 1.0033 144.37
Shared Pool 136 1.0034 141.37
Shared Pool 144 1.0034 139.37
11 rows selected.
❸ linux 系统下oracle 10G perl进程cpu占用100% ，这个进程有什么用能关掉吗会不会有什么影响
oracle 程序本身很多服务就是用perl编写的，不能结束。
100% 有两点，一种就是oracle 本身配置有问题， 可以通过查看日志。
还有一种就是客户端有人执行了一个很耗资源的sql并同时访问大量的数据。
下面几个sql应该可以帮你：
查询耗资源的进程（top session）
SELECT s.Schemaname Schema_Name,Decode(Sign(48 - Command),
1, To_Char(Command), 'Action Code #' || To_Char(Command)) Action,Status Session_Status, s.Osuser Os_User_Name, s.Sid, p.Spid,s.Serial# Serial_Num, Nvl(s.Username, '[Oracle process]') User_Name,
s.Terminal Terminal, s.Program Program, St.VALUE Criteria_Value
FROM V$sesstat St, V$session s, V$process p
WHERE St.Sid = s.Sid
AND St.Statistic# = To_Number('38')
AND ('ALL' = 'ALL' OR s.Status = 'ALL')
AND p.Addr = s.Paddr
ORDER BY St.VALUE DESC, p.Spid ASC, s.Username ASC, s.Osuser ASC
查看锁（lock）情况
SELECT /*+ RULE */ Ls.Osuser Os_User_Name, Ls.Username User_Name,Decode(Ls.TYPE,
'RW', 'Row wait enqueue lock', 'TM', 'DML enqueue lock','TX', 'Transaction enqueue lock', 'UL', 'User supplied lock') Lock_Type,o.Object_Name OBJECT,Decode(Ls.Lmode,1, NULL, 2, 'Row Share', 3, 'Row Exclusive',
4, 'Share', 5, 'Share Row Exclusive', 6, 'Exclusive',NULL) Lock_Mode,o.Owner, Ls.Sid, Ls.Serial# Serial_Num, Ls.Id1, Ls.Id2 FROM Sys.Dba_Objects o,
(SELECT s.Osuser, s.Username, l.TYPE, l.Lmode, s.Sid, s.Serial#, l.Id1,l.Id2 FROM V$session s, V$lock l
WHERE s.Sid = l.Sid) Ls
WHERE o.Object_Id = Ls.Id1
AND o.Owner <> 'SYS'
ORDER BY o.Owner, o.Object_Name;
根据sid查看对应连接正在运行的sql
SELECT /*+ PUSH_SUBQ */ Command_Type, Sql_Text, Sharable_Mem, Persistent_Mem, Runtime_Mem, Sorts,
Version_Count, Loaded_Versions, Open_Versions, Users_Opening, Executions,
Users_Executing, Loads, First_Load_Time, Invalidations, Parse_Calls,
Disk_Reads, Buffer_Gets, Rows_Processed, SYSDATE Start_Time,
SYSDATE Finish_Time, '>' || Address Sql_Address, 'N' Status
FROM V$sqlarea WHERE Address = (SELECT Sql_Address
FROM V$session WHERE Sid = &sid );
❹ oracle占用cpu过高 怎么处理
这个没办法处理优化，只能是提高电脑配置，或者是换其他版本的oracle，建议使用10g。
解释：oracle运行程序本身就比较占内存，并且要启动三个实例才可以运行，所以建议可以更换个大的内存条（最少4G），安装64位系统。
备注：建议不用oracle的情况下可以把oracle的进程都停掉，减少内存占用。
❺ Oracle11g由于应用sql语句问题造成IO高，cpu高，业务中断，请教解决方法！
你这个情况属于死翘翘的，所谓优化大部分都需要代码的，而且代码级别的优化是最简单最粗浅的了，绕开代码级别的优化属于架构级别的优化了，那样代价就更高了，而且代码级别的优化都做不到，那架构级优化就更难了。如果sql都优化不了，你就算增加内存，增加cpu,增加服务器，即使你改到小型机上，而代码本身却不能够使用这些资源，你也是白搭的，你现在目前能做的要么放任自流，要么重新组建开发团队开发了。
❻ 如何诊断和解决CPU高度消耗（100%）的数据库
oracle的性能判断需要综合数据库的多个运行指标来判断： 1、进程数量和占用cpu：这个主要看有没有长时间占用cpu的进行。通常会判断大出sql，需要优化；这个可以用执行计划或者awr报告查看； 2、内存占用：主要用系统命令查看ora_占用和系统
❼ Oracle数据库服务器CPU一直100%怎么办
topas/top 看下是不是oracle进程占用的cpu。
然后查看下oracle数据库中都在跑哪些语句。
多数都是效率较差的sql语句导致cpu使用率过高的，一般通过优化sql即可解决。
可用如下语句查看哪些执行时间较长的sql：
Select b.USERNAME,
b.SID,
a.SQL_ID,
a.SQL_TEXT,
a.sql_fulltext,
b.EVENT,
a.executions,
-- trunc(((decode(a.EXECUTIONS,0,0,a.cpu_time / a.executions)) / 10000)) c_time, ---单位零点秒
trunc(((decode(a.EXECUTIONS,0,0,a.ELAPSED_TIME / a.executions)) / 10000)) e_time,
--trunc(cpu_time/10000) cpu_time,
trunc(a.ELAPSED_TIME/10000) ELAPSED_TIME ,
a.DISK_READS,
a.BUFFER_GETS,
b.MACHINE,
b.PROGRAM
From v$sqlarea a, v$session b
Where executions > =0
And b.status = 'ACTIVE'
and a.SQL_ID = b.SQL_ID
-- and b.USERNAME='DB_WTDZ'
-- and trunc(((a.cpu_time / a.executions) / 1000000))>5
Order By e_time desc
❽ oracle 10g + 红帽企业板5.0 cpu利用率100%
可能是游标没有关闭
如果下次你再遇到这种情况,你可以执行以下sql语句,可以定位系统当前在执行什么操作
1.select ses.sid from v$session ses,v$process pro where pro.spid=进程号 and ses.paddr=pro.addr;
2.select sql_text from v$sqltext_with_newlines where (hash_value,address) in (select sql_hash_value,sql_address from v$session where sid=上一条SQL中查询出来的ses.sid) order by address,piece;
❾ oracle数据库经常会出现占用cpu100%的进程，然后系统就挂了，怎么找出引起这种故障的sql语句
在故障发生时，尝试用下面的语句抓取数据库引起故障的点。
/*********************************************************************************************/
在oracle中监控死锁
/*********************************************************************************************/
SELECT sn.username,
m.SID,
sn.SERIAL#,
m.TYPE,
DECODE(m.lmode,
0,
'None',
1,
'Null',
2,
'Row Share',
3,
'Row Excl.',
4,
'Share',
5,
'S/Row Excl.',
6,
'Exclusive',
lmode,
LTRIM(TO_CHAR(lmode, '990'))) lmode,
DECODE(m.request,
0,
'None',
1,
'Null',
2,
'Row Share',
3,
'Row Excl.',
4,
'Share',
5,
'S/Row Excl.',
6,
'Exclusive',
request,
LTRIM(TO_CHAR(m.request, '990'))) request,
m.id1,
m.id2
FROM v$session sn, v$lock m
WHERE (sn.SID = m.SID AND m.request != 0) --存在锁请求，即被阻塞
OR (sn.SID = m.SID --不存在锁请求，但是锁定的对象被其他会话请求锁定
AND m.request = 0 AND lmode != 4 AND
(id1, id2) IN (SELECT s.id1, s.id2
FROM v$lock s
WHERE request != 0
AND s.id1 = m.id1
AND s.id2 = m.id2))
ORDER BY id1, id2, m.request;
/*********************************************************************************************/
定位引起oracle死锁的sql
/*********************************************************************************************/
select sql_text from v$sql where hash_value in
(select sql_hash_value from v$session where sid in
(select session_id from v$locked_object))
/*********************************************************************************************/
下面的SQL查询可以用于确定锁住数据库对象的锁：
/*********************************************************************************************/
select
c.owner,
c.object_name,
c.object_type,
b.sid,
b.serial#,
b.status,
b.osuser,
b.machine
from
v$locked_object a ,
v$session b,
dba_objects c
where
b.sid = a.session_id
and
a.object_id = c.object_id;
/*********************************************************************************************/
显示哪些会话被锁住
/*********************************************************************************************/
/* showlock.sql */
COLUMN o_name format a10
COLUMN lock_type format a20
COLUMN object_name format a15
SELECT RPAD (oracle_username, 10) o_name, session_id SID,
DECODE (locked_mode,
0, 'None',
1, 'Null',
2, 'Row share',
3, 'Row Execlusive',
4, 'Share',
5, 'Share Row Exclusive',
6, 'Exclusive'
) lock_type,
object_name, xisn, xidslot, xidsqn
FROM v$locked_object, all_objects
WHERE v$locked_object.object_id = all_objects.object_id;
/*********************************************************************************************/
显示所有的TM和TX锁
/*********************************************************************************************/
/* showalllock.sql */
SELECT SID, TYPE, id1, id2,
DECODE (lmode,
0, 'None',
1, 'Null',
2, 'Row share',
3, 'Row Exclusive',
4, 'Share',
5, 'Share Row Exclusive',
6, 'Exclusive'
) lock_type,
request, ctime, BLOCK
FROM v$lock
WHERE TYPE IN ('TX', 'TM');
/*********************************************************************************************/
在Oracle数据库中,可以通过kill session的方式来终止一个进程,其基本语法结构为:
被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程.
我们发现当一个session被kill掉以后，该session的paddr被修改，如果有多个session被kill，那么多个session
的paddr都被更改为相同的进程地址:
/*********************************************************************************************/
alter system kill session 'sid,serial#' ;
/*********************************************************************************************/
在oracle中kill掉的进程有时还需要等待pmon回滚数据库已经占有的资源
有时候我们需要使用下面的脚本找出那些已经在oracle中kill掉的进程，在操作系统中在kill一次
/*********************************************************************************************/
select p.addr from v$process p where pid <> 1
minus
select s.paddr from v$session s;
$ kill -9 &paddr
❿ oracle 占用cpu太多
你的数据库的表记录数有多少？检查上千的表，看索引是否合理，是否有主键，查询一般是以什么条件在进行，相关字段是否有索引。
补充：
没起服务的机器，CPU100％是被哪个进程占的？然后才能进行分析和处理。