db time远大于elapsed时间是正常现象，因其为所有前台会话耗时总和（累积值），而elapsed是采样窗口实际时长；比值越大说明系统越繁忙。

db time远大于elapsed时间，说明什么？

AWR报告里DB Time动辄是Elapsed的几十倍甚至上百倍，这不是数据错了，而是它本就是累积值。比如采样窗口60分钟，8核CPU全忙，理论上最大DB CPU可达480分钟；100个会话各自等了2秒I/O，Non-idle wait就记作200秒——这些全部加总进DB Time。

• DB Time > Elapsed 是常态，且越“忙”的系统这个比值越大
• 如果DB Time ≈ Elapsed（比如都约等于60分钟），反而说明数据库几乎空转，连一个像样的用户请求都没进来
• 真正该警惕的是：在高并发场景下，DB Time增长远快于事务数或逻辑读，暗示单位工作负载耗时在恶化

CPU Time占比超100%？不是bug，是多核计时方式

你看到DB CPU占DB Time的105%，别急着截图发群问“Oracle算错了”。这是因DB CPU按CPU秒累加（N核×T秒），而DB Time是所有前台会话“感知到的时间”总和，二者量纲不同但共用“秒”单位，导致百分比可能突破100%。

• 单核系统上，DB CPU / DB Time不可能超100%
• 8核系统中，若所有核持续满载60分钟，DB CPU = 480秒，只要DB Time ，比例就>100%
• 关键看绝对值：DB CPU占DB Time超过90%，基本可判定CPU是瓶颈；若仅30%~50%，则等待事件（如db file sequential read、enq: TX）更值得深挖

DB CPU高但响应慢？先查是不是在“假忙”

DB CPU高，不代表SQL真在高效干活——可能是硬解析过多、绑定变量未用、执行计划反复生成，或者PL/SQL循环里做了大量无意义计算。

• 检查parse time elapsed是否占DB Time > 5%，高则说明硬解析泛滥
• 对比sql execute elapsed time与DB CPU：如果前者远大于后者，说明大量时间花在等待（比如锁、I/O），而非CPU计算
• 查V$SQL里PARSE_CALLS高但EXECUTIONS低的语句，这类“只编译不执行”或“执行极少却频繁硬解析”的SQL最伤CPU

健康比例没有固定值，要看业务类型和硬件配置

OLTP系统DB CPU占70%~85%通常合理，因为事务短平快，CPU密集；而报表类OLAP作业若DB CPU只占20%，反而是I/O或内存严重不足的信号——数据扫不完、排序落盘、大量物理读拖慢节奏。

• 虚拟机或云环境要注意：vCPU配额限制、CPU节流（throttling）会导致DB CPU虚高，实际调度延迟藏在wait on CPU queue里，但该指标默认不显式列出，需查V$SYS_TIME_MODEL中background cpu time以外的cpu queued time
• 同一业务，升级硬件后DB CPU占比下降不一定是好事——如果伴随physical reads暴增，可能是buffer cache没调优，CPU省了，I/O扛不住了

真正容易被忽略的，是把DB Time当单一会话耗时来读；它从来不是“一次请求花了多久”，而是“所有请求耗时的总工时”。盯错维度，优化方向就全偏了。