| OS | 指令/工具 | 關鍵指標 |
|---|---|---|
| Linux/Unix | sar -u 1 10, top, vmstat | %user, %system, %iowait, %idle |
| Windows | 效能監視器 | Processor Time, Privileged Time, User Time |
SELECT
(SELECT value FROM v$sysstat WHERE name = 'CPU used by this session') / 100 AS db_cpu_sec,
(SELECT value FROM v$sysstat WHERE name = 'OS User level CPU time') / 100 AS os_user_cpu_sec,
(SELECT value FROM v$sysstat WHERE name = 'OS System call CPU time') / 100 AS os_sys_cpu_sec
FROM dual;
若 DB CPU / (OS User + OS System) > 90% → 資料庫佔用絕大多數 CPU。
SELECT s.sid, s.serial#, s.username, s.module, s.machine,
st.value/100 AS cpu_seconds
FROM v$session s, v$sesstat st, v$statname sn
WHERE st.statistic# = sn.statistic#
AND sn.name = 'CPU used by this session'
AND st.value > 0
ORDER BY st.value DESC;
SELECT name, value
FROM v$sysstat
WHERE name IN ('parse time cpu', 'parse time elapsed', 'parse count (hard)');
parse time cpu:解析消耗的 CPU 時間(百分秒)parse time elapsed:解析經過時間(百分秒)parse count (hard):硬解析次數SELECT
(parse_elapsed - parse_cpu) / NULLIF(parse_count, 0) AS avg_parse_wait_cs
FROM (
SELECT
MAX(DECODE(name, 'parse time cpu', value)) parse_cpu,
MAX(DECODE(name, 'parse time elapsed', value)) parse_elapsed,
MAX(DECODE(name, 'parse count (hard)', value)) parse_count
FROM v$sysstat
WHERE name IN ('parse time cpu', 'parse time elapsed', 'parse count (hard)')
);
理想值應接近 0。若偏高,表示解析階段有嚴重等待(Latch 競爭、共用池不足)。
SELECT sql_text, parse_calls, executions,
parse_calls / NULLIF(executions, 0) AS parse_per_exec
FROM v$sqlarea
WHERE executions > 0
ORDER BY parse_calls DESC;
parse_calls / executions > 1 表示重複解析(未使用繫結變數或游標未共用)。
| 問題根因 | 對策 | 相關參數/動作 |
|---|---|---|
| SQL 重複硬解析 | 使用繫結變數、游標共用 | CURSOR_SHARING=FORCE/SIMILAR, SESSION_CACHED_CURSORS |
| 低效執行計劃 | SQL 調優、統計資訊收集、Hint | DBMS_STATS, SQL Tuning Advisor |
| 鎖競爭 | 縮短交易、索引優化、分區 | V$LOCK, V$SESSION_WAIT 分析 |
| 共用池不足 | 增加共用池、KEEP 池釘住熱門物件 | SHARED_POOL_SIZE, DBMS_SHARED_POOL.KEEP |
| 遞歸 SQL 過多 | 審查 DDL、PL/SQL 動態 SQL、審計 | V$SQL 指令類型分析 |
SESSION_CACHED_CURSORS:預設 50,建議 200-500,減少軟解析開銷CURSOR_SHARING:EXACT(預設) → FORCE 可緊急緩解字面值 SQL 暴增,但可能產生次優計劃OPEN_CURSORS:確保足夠(預設 300,建議 1000+)避免 ORA-01000CPU 調優核心在於減少不必要的解析與優化高消耗 SQL 的執行計劃。建立「OS 監控 → DB 統計 → Session 熱點 → SQL 解析 → 執行計劃」的分層診斷流程,配合 AWR/ASH 報表定期審視,才能系統性解決 CPU 瓶頸。