Oracle 12c CPU占用过高根源在于SQL执行计划失当、硬解析泛滥或latch争用，需通过AWR报告分析DB CPU占比、Top SQL的CPU per Exec、硬解析比例及OS统计交叉验证，而非简单杀进程。
oracle 12c 进程 cpu 占用过高，大概率不是“某个进程疯了”，而是 sql 执行计划失当、硬解析泛滥或 latch 争用导致的系统级资源消耗。直接杀进程或重启实例只能掩盖问题，awr 报告才是定位根因的可靠依据。
看 DB CPU 是否真高：别被操作系统 top 带偏
OS 层看到 oracle 进程 CPU 使用率 90%，不等于数据库内部真在满负荷计算。关键要看 AWR 里的 DB CPU 在 DB Time 中的占比：
- 如果
DB CPU占DB Time超过 70%，且Average Active Sessions (AAS) = DB Time / Elapsed Time显著大于 CPU 核数（比如 12 核机器 AAS 达到 18），说明 CPU 确实是瓶颈源头 - 若
DB CPU占比低，但latch: shared pool或latch: library cache等等待事件排进 Top 5，则真实问题是硬解析过多，CPU 消耗在闩锁争用上，而非 SQL 计算本身 - 注意：
DB CPU是累计值——12 核机器 1 秒内最多贡献 12 秒 CPU 时间；报告里显示 3600 秒 DB CPU，意味着平均每秒消耗了 60 秒 CPU（即 5 个核持续满载）
查 Top SQL 的 CPU per Exec：揪出单次执行最“烧 CPU”的语句
在 AWR 报告的 SQL Statistics → SQL ordered by CPU Time 部分，不能只看总 CPU 时间排序，必须下钻到 CPU per Exec 列：
- 排除
EXECUTIONS = 0但CPU_TIME_SEC > 0的伪高负载 SQL（常见于统计未刷新或游标异常终止） - 重点关注
CPU per Exec > 10秒的 SQL，尤其是执行频率不低（Executions per Sec > 0.1）的——这类语句每秒都在稳定吃 CPU - 对比正常时段报告：同一 SQL 在问题时段
CPU per Exec突增 3 倍以上，基本可锁定为执行计划劣化（如索引失效、统计信息陈旧） - 用
DBMS_XPLAN.DISPLAY_AWR('<sql_id>', NULL, 'ALLSTATS LAST')</sql_id>查其实际执行计划，确认是否出现全表扫描、嵌套循环放大、FILTER 操作等高 CPU 模式
盯住 Parse CPU to Parse Elapsd 和 Hard Parse 比例：识别绑定变量缺失
Oracle 12c 默认启用自适应游标共享和 SQL Plan Directives，但若应用未使用绑定变量，仍会触发大量硬解析，把 CPU 耗在语法分析、权限校验、执行计划生成上：
- 在
Instance Efficiency Percentages区域，检查Parse CPU to Parse Elapsd %—— 若低于 20%，说明解析过程大量卡在等待（如 latch），而非真正计算 - 在
Instance Activity Stats中查找parse count (hard)和parse count (total)：若前者 / 后者 > 10%，就是硬解析严重过载的明确信号 - 结合
SQL ordered by Parse Calls，找出调用次数极高但未使用绑定变量的 SQL（典型如WHERE id = 123写死字面量） - 验证方式：在测试环境关闭
cursor_sharing = force后重放相同负载，观察硬解析数是否骤降
交叉验证 OS 统计与 AWR：避开采样盲区
AWR 快照默认每小时一次，而 CPU 尖刺可能只持续几分钟。单靠 AWR 容易错过瞬时峰值：
- 务必同步查看 AWR 报告中
Operating System Statistics部分的BUSY_TIME和USER_TIME：若USER_TIME占比远高于SYS_TIME，说明 CPU 消耗集中在用户态（即 Oracle 自身逻辑，非内核调度） - 用
V$ACTIVE_SESSION_HISTORY补充秒级视图：SELECT sql_id, event, COUNT(*) FROM DBA_HIST_ACTIVE_SESS_HISTORY WHERE SAMPLE_TIME > SYSDATE - 1/24 AND session_state = 'ON CPU' GROUP BY sql_id, event ORDER BY 3 DESC - 注意 AWR 保留策略：12c 默认保留 8 天，若问题发生在 10 天前，快照已被清理，需提前调整
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
真正难的不是找到高 CPU SQL，而是区分它是业务增长带来的合理压力，还是统计信息偏差、执行计划漂移、或应用层绑定变量缺失引发的病理消耗——这需要你手上有问题时段 + 正常时段两份 AWR 报告做横向比对，缺一不可。
