db time高不等于cpu过载，需先计算aas并拆解构成：db time/(elapsed×cpu_count)＞1.2需深挖，＞2.0基本存在排队瓶颈；集群须按单实例计算，db time仅含前台会话，后台延迟需单独分析top events。
DB Time高不等于CPU过载，先算AAS再拆构成
DB Time数值本身没意义，关键看它和Elapsed Time、CPU数的比值。直接查v$osstat确认逻辑CPU总数：SELECT COUNT(*) FROM v$osstat WHERE stat_name = 'NUM_CPUS'。然后手工算：DB Time / (Elapsed × CPU_COUNT)。结果＞1.2就得深挖，＞2.0基本确定存在排队瓶颈。
别被“DB Time=3000分钟”吓住——如果快照间隔60分钟、16核，理论最大960分钟，实际3000分钟意味着平均时刻有约3个请求在争资源，不是CPU不够，是某类操作卡住了。
- 集群环境必须按单实例算，不能用总CPU数除整个DB Time
- DB Time只含前台会话，后台进程（如归档、CKPT）导致的延迟不会计入，得单独看Top Events里的后台事件
- Load Profile里DB Time单位是“per second”，和Report Summary里的绝对值不是一回事，别混用
直奔Time Model Statistics，定位耗时大头
跳过Load Profile和Top Events，先看AWR报告里的Time Model Statistics节——这才是DB Time的原始拆分表。重点关注三项：
-
DB CPU：前台会话真实占用CPU的时间。占比＞60%且resmgr:cpu quantum在Top Events里靠前，大概率是Resource Manager限频，不是硬件问题 -
sql execute elapsed time：SQL执行总耗时（含等待+CPU）。占DB Time 95%以上，说明瓶颈确实在SQL层；若远低于DB Time，就要查其他子项 -
parse time elapsed或hard parse elapsed time突增，结合parse count (hard)是否超parse count (total)的10%，锁定绑定变量缺失或cursor_sharing配置问题
如果PL/SQL execution elapsed time异常高，得检查是否有大量低效过程调用或递归SQL。
Top Events要交叉看三列，别只盯占比
比如log file sync占比只有3%，但一小时发生420万次、平均等待712µs，实际每秒提交超1160次——这是事务粒度太细，不是磁盘慢；gc buffer busy acquire占比1.2%但平均等待18ms，且只由7个活跃会话触发，基本锁定RAC热点块争用。
- 跳过所有以
SQL*Net message from client开头的空闲事件，除非它冲进Top 3且Avg Wait＞100ms -
enq: TX - row lock contention可能只排第9，但只要Wait Time占DB Time＞1%，就得手动搜enq:并结合DBA_HIST_ACTIVE_SESS_HISTORY下钻 - RAC下
DB Time必须按实例拆分看，用awrrpti.sql生成per-instance报告，否则节点负载不均会被掩盖
Redo Log配置不当常被忽略，但极易引发DB Time飙升
当log file switch (checkpoint incomplete)在Top Events里靠前，基本就是Redo Log文件太小。估算方法：从AWR报告里取Redo size per second（比如1.09 MB/s），乘以60再乘以期望的切换间隔（如30分钟），得出最小总容量需≥2.0 GB。
- 建议每个Redo Log文件设为200MB～500MB，至少配4组，避免每20～30分钟就切一次
- 新增日志组后，用
ALTER SYSTEM SWITCH LOGFILE多次，等旧组状态变为INACTIVE再删 - 删旧组前务必确认
v$log里STATUS列已无CURRENT或ACTIVE，否则会报错
真正难的是判断“高DB Time”到底属于健康高吞吐还是病理排队——这取决于AAS是否持续超标、等待事件是否集中在某类资源、以及SQL执行效率是否同步恶化。单看一个数字，永远解不开。
