❶ 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％是被哪個進程占的？然後才能進行分析和處理。