DB Time远超时钟时间属正常现象，本质是并发会话消耗的数据库服务时间总和；其值取决于活跃会话数与各会话平均耗时，公式为Σ(CPU时间+等待时间)，不可直接跨报告相减，须用awrddrpt.sql归一化对比。
db time远超实际经过的时钟时间是完全正常的现象，不是数据库出错，也不是报告失真——它反映的是所有活跃会话在该时间段内“合计消耗的数据库服务时间”，本质是并发累加值。
DB Time本质是并发会话时间总和，不是单个时钟刻度
比如一个60分钟的AWR快照区间（Elapsed: 60.00 mins），若期间平均有10个活跃用户会话，每个会话平均占用数据库资源3分钟，那DB Time就是 10 × 3 = 30分钟；如果平均有20个会话、每个耗5分钟，DB Time就变成100分钟——它天然可以、也经常远大于60分钟。
关键公式：DB Time = Σ(每个会话的 CPU 时间 + 等待时间)，而Elapsed Time只是这个统计窗口的物理长度。
- DB Time高 ≠ 数据库慢，只说明“总工作量大”或“并发高”
- DB Time
- DB Time / Elapsed Time 的比值 ≈ 平均活跃会话数（Active Session Count），这是判断负载密度的核心速算指标
Top 5 Timed Events里CPU time排第一，但DB Time仍异常高？
当CPU time出现在Top 5事件首位，且DB Time显著高于Elapsed Time，说明瓶颈不在I/O或锁等待，而是大量SQL正在争抢CPU资源——这时候要警惕低效SQL引发的“CPU密集型排队”。
- 检查
SQL ordered by CPU Time部分，看前3名SQL是否占了总CPU的50%以上 - 注意
Buffer Gets per Exec是否超高（比如>10万），意味着逻辑读爆炸，可能缺索引或走了全表扫描 - 留意
Executions和Elapsed Time per Exec是否严重不匹配：执行次数少但单次耗时长，大概率是硬解析+复杂执行计划 - 别只盯
Elapsed Time排序——CPU Time排序更能暴露纯计算瓶颈
用awrddrpt.sql做时段对比时，DB Time数值不可直接相减
两个AWR报告的DB Time数值不能简单相减来判断性能变化，因为DB Time本身依赖快照时长和并发基数。直接对比会导致误判。
- 必须用
awrddrpt.sql生成Diff报告，它会自动归一化为“per second”或“per transaction”，消除时段长度差异影响 - 如果手动对比两份
awrrpt.sql输出，DB Time列单位其实是“分钟总数”，而DB Time per Sec才是可比指标（即AAS，Average Active Sessions） - 哪怕时段长度相同，若baseline快照期间发生实例重启（
startup_time不一致），所有历史快照的DB Time统计基准就失效，Diff结果不可信
真正容易被忽略的点是：DB Time本身不带上下文。单独看一个数字毫无意义，必须绑定到具体快照区间、关联Top SQL和Top Events，再结合Average Active Sessions曲线看趋势——否则你优化的可能根本不是业务感知到的瓶颈。
