首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 數據庫知識 >  >> Oracle 資料庫 >> Oracle 資料庫基礎

Oracle CPU 效能調優實戰:監控指標、解析分析與優化策略

     編輯:Oracle 資料庫基礎

CPU 使用率健康基準

  • 尖峰期 90%+:正常,資源充分利用
  • 閒置期 90%+:警訊,CPU 資源不足
  • 尖峰期持續偏低:CPU 閒置,可能為 I/O 等待、鎖競爭或配置過度

作業系統層級監控

OS指令/工具關鍵指標
Linux/Unixsar -u 1 10, top, vmstat%user, %system, %iowait, %idle
Windows效能監視器Processor Time, Privileged Time, User Time

資料庫層級 CPU 消耗分析

1. 總體 CPU 消耗佔比

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。

2. Session 級 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;

SQL 解析效能診斷

關鍵統計項

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 競爭、共用池不足)。

找出高解析 SQL


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 調優、統計資訊收集、HintDBMS_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-01000

總結

CPU 調優核心在於減少不必要的解析與優化高消耗 SQL 的執行計劃。建立「OS 監控 → DB 統計 → Session 熱點 → SQL 解析 → 執行計劃」的分層診斷流程,配合 AWR/ASH 報表定期審視,才能系統性解決 CPU 瓶頸。

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved