db time异常高不等于cpu过载，需拆解其构成（db cpu+非空闲等待）定位根因；db time > elapsed × cpu数表明请求已超并行承载上限，如16核60分钟理论最大960分钟，达2800分钟即平均2.9个请求排队争抢。
awr报告里db time异常高，不等于cpu过载；真正要盯的是db time的构成——它由db cpu和各类非空闲等待时间叠加而成，拆开看才能定位根因。
DB Time远大于Elapsed × CPU数，说明什么
这不是“数据库忙”的模糊判断，而是明确信号：用户请求在数据库内累积消耗的时间，已超出物理资源能并行承载的理论上限。比如16核服务器、快照间隔60分钟，理论最大DB Time是960分钟（16×60）；若报告中DB Time达2800分钟，说明平均每个时刻有约2.9个请求在排队或争抢资源。
常见错误现象：DB Time数值本身没单位感，直接对比Elapsed却忽略CPU数量，误判为“只是IO慢”或“纯SQL问题”。
- 必须先查清逻辑CPU总数：
SELECT COUNT(*) FROM v$osstat WHERE stat_name = 'NUM_CPUS'或读/proc/cpuinfo -
DB Time / (Elapsed × CPU_COUNT)> 1.2 就该深入分解，> 2.0 基本存在明显瓶颈 - 注意：集群环境需按单实例计算，别用总CPU数除整个DB Time
从Time Model Statistics定位主要耗时模块
跳过Load Profile和Top Events，直奔AWR报告里的Time Model Statistics节——这里才是DB Time的原始拆分表。关键看三项：
-
DB CPU：前台会话真实占用CPU的时间（不含后台进程） -
sql execute elapsed time：SQL执行总耗时（含等待+CPU），通常最接近DB Time -
PL/SQL execution elapsed time、parse time elapsed等子项：确认是否被某类操作主导
使用场景：若sql execute elapsed time占DB Time 95%以上，说明瓶颈确实在SQL执行层；若parse time elapsed占比突增（尤其硬解析相关项），就要查绑定变量缺失或cursor_sharing配置问题。
容易踩的坑：background elapsed time不计入DB Time，所以后台进程（如归档、CKPT）导致的延迟不会体现在这里——得单独看Top 5 Timed Foreground Events里的后台事件。
结合Top 10 Foreground Events验证等待类型
Time Model告诉你“哪类操作耗时多”，Top Events告诉你“卡在哪种资源上”。两者必须对照看：
- 如果
DB CPU占比高（>60%），但Top Events里resmgr:cpu quantum排前三，说明是Resource Manager人为限频，不是硬件瓶颈 - 若
direct path read或db file sequential read靠前，且DB CPU占比低（ -
enq: TX - row lock contention或latch: shared pool出现，对应Hard Parses飙升，基本锁定共享池争用或未绑定变量
参数差异：Top 10 Foreground Events默认只统计前台会话，而Top 10 Background Events需手动翻页查看——漏看后者可能错过归档慢、日志切换卡顿等问题。
为什么不能只看Load Profile里的Per Second指标
Load Profile中Parses、Executes、Redo size等每秒值，是平均值，掩盖了毛刺。一个持续2分钟的硬解析风暴，可能把整小时的Hard Parses拉到80/s，但实际业务只在那两分钟卡死。
性能影响：平均值对OLTP系统误导性极强。更有效的是用DBA_HIST_SYS_TIME_MODEL和DBA_HIST_SYSTEM_EVENT按快照ID逐点查询，画出DB CPU和Top Event的分钟级趋势线。
实操建议：
- 用
SELECT snap_id, round(db_time / 60, 2) db_time_min FROM dba_hist_sys_time_model WHERE stat_name = 'DB time' AND snap_id BETWEEN 1000 AND 1010快速提取连续快照的DB Time变化 - 避免依赖AWR默认的1小时快照粒度；压测或故障时段，应提前设为30秒或5分钟快照（
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS）
复杂点在于：DB Time高可能是多个小问题叠加的结果——比如少量硬解析 + 中等IO延迟 + 轻微锁争用，每项都不触发告警阈值，但合起来就让响应时间翻倍。这时候必须回到Time Model做加法验证，而不是只盯着单项Top Event。
