AWR中不存在独立的Wait Time字段，所谓“Wait Time超过Elapsed Time”实为DB Time减DB CPU得出的非空闲等待总和，它是所有会话等待时间的累加值，天然可超Elapsed Time。
wait time 不可能真正超过 elapsed time——如果你在 oracle 11g 的 awr 报告里看到类似现象，说明你误读了指标来源或混淆了统计口径。awr 中根本不存在一个叫 wait time 的独立字段；你实际看到的，是 db time 减去 db cpu 后推算出的“非空闲等待总和”，而这个值本身可以（也经常）大于 elapsed time，但它不是“单个会话的等待时长”，而是所有活跃会话等待时间的**累加和**。
DB Time 和 Elapsed Time 的关系不是 1:1 对应
这是最常被误解的起点。DB Time 是所有前台会话在报告时段内消耗的数据库时间总和（单位：分钟），包括：CPU time + non-idle wait time。而 Elapsed Time 就是两个快照之间的真实物理时间（比如 60 分钟）。只要同时有多个会话在运行，DB Time 就天然可远超 Elapsed Time。
- 例如：16 核服务器上，60 分钟内有 100 个会话轮流执行、排队、等待，
DB Time达到 4800 分钟完全正常（平均 AAS = 4800 / 60 = 80） -
DB Time > Elapsed Time本身不表示异常，只说明系统负载高；但若DB Time >> (CPU Count × Elapsed Time)（比如 16 核下 DB Time 是 Elapsed 的 10 倍），才提示严重排队或资源争用 - Oracle 11g 没有改变这一计时逻辑，它和 10g/12c 一致；所谓“11g 中 Wait Time 超过 Elapsed”只是把
DB Time − DB CPU错当成了单一会话等待时长
Top 5 Timed Events 里的 Wait Time 是占比，不是绝对值
你在 “Top 5 Timed Events” 表格里看到的每一行的 Time (s) 列，是该等待事件在全部 DB Time 中所占的秒数（注意：是累计值，不是平均值）。它的总和 ≈ DB Time − DB CPU，因此必然 ≤ DB Time，但和 Elapsed Time 无直接可比性。
- 常见错误：看到
db file sequential read一行写着Time (s): 12480（即 208 分钟），而Elapsed Time才 60 分钟，就断言“IO 等待比总时间还长”——错。这 208 分钟是所有会话加起来等磁盘的总耗时 - 真正有意义的是该事件的
%Total Call Time：如果它占到 65%，说明近三分之二的数据库时间花在等单块读上，这才是瓶颈信号 - 不要用单行
Time (s)去除以Elapsed Time算“每秒等待次数”，那是无效操作；要看 “Wait Class” 或 “Load Profile” 里的Waits/sec
DB CPU 和 OS 层 CPU 使用率不是一回事
很多人拿 AWR 里的 DB CPU 直接对标 top 或 vmstat 的 %us，结果对不上。因为：
-
DB CPU只统计前台会话（user process）在 Oracle 内核代码中实际占用 CPU 的时间，不含后台进程（如LGWR、DBWR）、OS 调度开销、中断处理、以及 Oracle 进程在用户态（如 OCI 层）的 CPU 消耗 - Linux
%us是整个 CPU 时间片中，所有用户态进程（含 Oracle 进程、监听器、shell 等）占用的比例，范围更宽 - 典型偏差场景：大量硬解析时，
DB CPU高但 OS %us 不高（因为解析主要耗在 library cache latch 争用上，CPU 实际执行少）；或大量 direct path read 时，DB CPU低但 %us 高（数据从磁盘拷贝到 PGA 占用 CPU）
真正容易被忽略的是：AWR 报告中所有时间类指标都依赖 STATISTICS_LEVEL = TYPICAL（默认值）。如果被误设为 BASIC，DB Time、DB CPU、等待事件等关键字段将全为 0 或不可信——查 v$parameter 确认该参数值，比纠结“Wait Time 超没超 Elapsed”重要得多。
