DB Time异常升高不等于数据库变慢或CPU过载，而是用户会话在数据库内累计消耗时间增多；需计算AAS（DB Time/Elapsed）并结合CPU核数判断资源争抢程度，再通过Time Model Statistics定位耗时主因。
DB Time异常升高，不等于数据库变慢或CPU过载——它只是说明用户会话在数据库内累计消耗的时间变多了，真正要拆开看的是这时间花在哪了。
先算AAS和CPU理论上限，别被绝对值吓住
AWR报告开头的DB Time和Elapsed两个数不能直接比。关键指标是AAS = DB Time / Elapsed（单位：活跃会话数）。OLTP系统AAS持续>5、报表类>10才需警惕；低于2基本可排除全局排队。
- 必须查真实CPU核数：
SELECT COUNT(*) FROM v$osstat WHERE stat_name = 'NUM_CPUS'，别用cat /proc/cpuinfo | grep processor | wc -l算逻辑核 - 理论最大DB Time =
CPU_COUNT × Elapsed（分钟）。比如16核、60分钟快照，上限是960分钟；若报告中DB Time达2800分钟，说明平均时刻有2.9个请求在争抢资源 -
DB Time / (Elapsed × CPU_COUNT) > 1.2就该往下拆，>2.0基本存在瓶颈
直奔Time Model Statistics，定位耗时主因
跳过Load Profile和Top Events，先看AWR报告里Time Model Statistics节——这才是DB Time的原始构成表。重点盯三项：
-
DB CPU：前台会话真实占用CPU时间。占比DB Time又很高，说明等待占大头，不是CPU问题 -
sql execute elapsed time：SQL执行总耗时（含等待+CPU），通常最接近DB Time。若它占DB Time95%以上，瓶颈确实在SQL层 -
parse time elapsed或PL/SQL execution elapsed time突增：说明硬解析或PL/SQL调用成了主力消耗，不是SQL本身慢
注意：background elapsed time不计入DB Time，所以归档、CKPT等后台延迟不会体现在这里。
Top 5 Timed Foreground Events要交叉看三列
只看“占比”会误判。必须同时看Wait Time、Waits、Avg Wait (ms)三列：
-
log file sync占比3%，但一小时发生420万次、平均712 µs → 实际每秒提交超1160次，是事务粒度太细，不是磁盘慢 -
gc buffer busy acquire占比1.2%，但平均等待18 ms且仅由7个会话触发 → RAC热点块争用，跟整体负载无关 - 所有以
SQL*Net message from client开头的空闲事件，除非冲进Top 3且Avg Wait>100ms，否则直接忽略
DB Time高但Top SQL合计占比低，问题往往不在SQL
如果DB CPU占DB Time70%，但前10条SQL加起来只占总CPU的15%，说明大量时间耗在非SQL路径：
- 查
v$sql里cpu_time/elapsed_time比值：若普遍偏低（如 - 查硬解析：
parse count (hard)是否远高于parse count (total)的10%，确认是否存在绑定变量缺失 - 用ASH抓实时咬CPU的SQL：
SELECT sql_id, COUNT(*) FROM v$active_session_history WHERE session_state = 'ON CPU' AND sample_time > SYSDATE - 1/24 GROUP BY sql_id ORDER BY 2 DESC，避开AWR聚合失真
最容易被忽略的是采样粒度——AWR快照是分钟级聚合，短时尖峰会被抹平；而DB Time本身不含后台进程耗时，单看它无法覆盖LGWR、ARCH等关键路径的延迟。
