1:檢查系統(tǒng)sar -u 5 52: 看誰在用CPUtopasps -ef grep ora #檢查第四列，C的大小(unit，100 per cpu)　　3:檢查CPU數量/usr/sbin/bindprocessor -qlsattr El proc04:兩種可能：1: A Background (instance) process2: An Oracle (user) process #此種可能最大。5: 假如是用戶進程：那么高CPU的主要原因有：Large Queries, Procedure compilation or execution,Space management and Sorting5.1 查看每個Session的CPU利用情況：select ss.sid,se.command,ss.value CPU ,se.username,se.programfrom v$sesstat ss, v$session sewhere ss.statistic# in(select statistic#from v$statnamewhere name = 'CPU used by this session')and se.sid=ss.sidand ss.sid>6order by ss.sid5.2: 比較上述Session比較一下哪個session的CPU使用時間最多，然后查看該Session的具體情況：select s.sid, event, wait_time, w.seq#, q.sql_textfrom v$session_wait w, v$session s, v$process p, v$sqlarea qwhere s.paddr=p.addr ands.sid=&p ands.sql_address=q.address;5.3:查看得到上述信息后，查看相應操作是否有hash joins 和 full table scans。假如有hash joins 和 full table scans那么必須創(chuàng)建相應的Index或者檢查Index是否有效。另外必須檢查是否有并行的查詢存在和同一時刻有多個用戶在執(zhí)行相同的SQL語句，假如有必須關閉并行的查詢和任何類型的并行提示(hints);假如查詢使用intermedia數據，那么為了減少總的Index大小，必須限制使用Intermedia的Worldlist。(try restricting the Wordlist that intermedia uses to help redUCe the total indexsize)。6:注重事項上述方案只能根據已經運行完成的操作，對于正在執(zhí)行的長時間操作只能等操作完成后才能檢測得到。因此我們可以通過另外一個很好的工具來檢測正在運行的長時間操作語句。v$session_longops,這個視圖顯示那些操作正在被運行，或者已經完成。每個process完成后會刷新本視圖的信息。7:怎樣尋找集中使用CPU的Process：很多時候會發(fā)現有N個Process在平均分享著CPU的利用率，這種情況唯一的可能性就是這些Process在執(zhí)行著相同的Package或者Query.這種情況：建議通過statspack,在CPU高利用率額時候運行幾個快照，然后根據這些快照檢查Statspack報告，檢查報告中最TOP的Query。然后使用 sql_trace and tkprof 工具去跟蹤一下。同時檢查buffer cache 的命中率是否大雨95%。同時在報告中還需要檢查一下table scans (long tables)，看是否在報告生成期間有存在全表掃描。8:參數另外還有一些不是非凡重要的，但是也必須關心檢查的參數可能消耗CPU。parallel query 并行查詢：并行查詢最好用于數據倉庫的環(huán)境下，那種情況任何時候只有幾個用戶在同時使用。在一個聯機事務處理環(huán)境中，當同時許多用戶去并行查詢一個數據庫的巨大表時候，會導致CPU的爆滿。所以最好在數據庫的級別關閉并行查詢：設置參數如下：parallel_min_server = 0parallel_max_server = 0parallel_automatic_tuning = false;在配置上述參數后，假如SQL語句中使用的并行的提示，那么還是有可能會出現并行查詢的情況，所以還需要繼續(xù)監(jiān)視相關的SQL語句，假如有可以直接去除提示。