Oracle 19c CPU高需以AWR报告为准：先看DB CPU/DB Time占比是否超40%、AAS是否持续超核数，再查SQL ordered by CPU Time中CPU per Exec >5且Executions/sec >0.1的语句，同时关注硬解析异常和plan_hash_value突变。
Oracle 19c中CPU利用率高，不能只看操作系统top里oracle进程占了90%就动手杀会话——AWR报告里的DB CPU占DB Time比重、Average Active Sessions是否超核数、以及SQL ordered by CPU Time里每条SQL的CPU per Exec值，才是判断真瓶颈的关键。
怎么看DB CPU是否真高：别被OS层假象带偏
操作系统看到oracle进程CPU使用率85%，不代表数据库内部真在满负荷计算。必须进AWR报告看Time Model Statistics页：
-
DB CPU占DB Time比例低于40%？那大概率不是SQL执行问题，而是latch: shared pool或library cache争用导致CPU耗在解析等待上 -
Average Active Sessions（AAS）=DB Time/Elapsed Time，若12核机器AAS持续>15，才说明并发活跃度真压垮了CPU资源 -
DB CPU数值是累计值：报告里显示3600秒，意味着该时段平均每秒消耗了300秒CPU时间（即25核等效满载），远超物理核数
查SQL ordered by CPU Time：重点看CPU per Exec，不是总CPU
AWR默认按累计CPU时间排序，但真正拖垮系统的往往是那些单次执行就吃掉10秒CPU、且每秒执行多次的语句：
- 跳过
EXECUTIONS = 0但CPU_TIME_SEC > 0的SQL——这类是游标异常终止或统计未刷新的干扰项 - 重点关注
CPU per Exec > 5且Executions per Sec > 0.1的SQL，它们才是稳定输出CPU压力的“定时炸弹” - 同一
sql_id在不同快照里CPU per Exec突增3倍以上？立刻用DBMS_XPLAN.DISPLAY_AWR('<sql_id>')</sql_id>查执行计划，确认是否出现FULL TABLE SCAN或NESTED LOOPS放大
硬解析失控时，CPU高但Top SQL不显眼
当Parse CPU to Parse Elapsd %低于20%，或parse count (hard)每小时超过500次，说明大量CPU耗在语法校验、权限检查、计划生成上，而不是SQL执行本身：
- 检查应用是否漏写绑定变量——
sql_text里带字面量（如WHERE id = 123）而非WHERE id = :b1 - 确认NLS参数是否漂移：
v$session里nls_language、nls_territory不一致会导致相同SQL被当成不同语句硬解析 - 查
dba_hist_sqlstat中parse_calls ≈ executions的SQL，这类就是硬解析失控的典型
plan_hash_value突变比SQL本身更危险
AWR报告只列Top 30 SQL，且不标记执行计划是否变化。很多CPU飙升源于plan_hash_value从12345变成67890，但报告里根本看不出：
- 手动查
DBA_HIST_SQLSTAT：SELECT sql_id, plan_hash_value, executions, ROUND(elapsed_time / NULLIF(executions, 0)) cpu_per_exec FROM dba_hist_sqlstat WHERE sql_id = '<your_sql_id>' ORDER BY snap_id</your_sql_id> - 对比相邻快照的
plan_hash_value，突变即风险；再结合DBA_HIST_SQL_PLAN查具体变更点（比如是否新增INDEX RANGE SCAN但没走索引） - 注意
is_bind_sensitive和is_bind_aware字段：若为YES但child_number > 1，说明已触发自适应游标共享，但可能因绑定变量窥探失效引发计划抖动
真正容易被忽略的是：AWR快照间隔默认1小时，而很多CPU尖峰只持续3–5分钟。如果没手动打快照，这些瞬时峰值就永远丢失了——哪怕你把报告翻烂，也找不到那个“定时炸弹”SQL。
