Time Model Statistics 更早暴露瓶颈本质，因其直接统计前台会话时间归属，字段互斥、总和恒等于DB Time，单位统一为秒，不受事件分类或采样偏差影响；例如sql execute elapsed time占比超100%而DB CPU仅40%，说明六成执行时间消耗在锁、I/O或网络等非CPU资源上，可避免被“CPU time”表象误导。
Time Model Statistics 为什么比 Top 5 Timed Events 更早暴露瓶颈本质
因为 time model 统计的是数据库内部所有前台会话的“时间归属”，它不依赖等待事件分类逻辑，也不受采样偏差或事件合并策略影响——sql execute elapsed time、db cpu、parse time elapsed 这些字段直接来自底层计时器，单位统一为秒，且彼此互斥、总和恒等于 db time。当你发现 sql execute elapsed time 占比超 100%（常见于高并发 oltp），而 db cpu 只占 40%，就说明近六成的 sql 执行时间花在了非 cpu 资源上，比如锁、i/o 或网络往返，这时再回头查 top 5 timed events 就不会被 “cpu time” 表象误导。
如何用 Time Model 快速排除伪 CPU 瓶颈
很多 DBA 看到 DB CPU 占比高就立刻调优 SQL 或加 CPU，结果无效。真正要盯的是两个比例关系：
-
DB CPU/DB Time> 70%：才值得深挖计算密集型 SQL；否则高 DB CPU 很可能是“等待导致的 CPU 空转”，比如硬解析时反复扫描 shared pool latch 链 -
hard parse elapsed time/parse time elapsed> 30%：说明解析开销主要来自硬解析，不是软解析或语法检查，该查绑定变量缺失或cursor_sharing设置 -
PL/SQL execution elapsed time占比突增（如从 0.5% → 8%）：往往对应存储过程批量逻辑改写、隐式类型转换或未启用 PL/SQL 函数结果缓存
Time Model 里容易被忽略但关键的三个隐藏指标
它们不出现在 Top 5，却能交叉验证瓶颈类型：
-
connection management call elapsed time：值异常高（>5%）说明连接池配置不当或应用频繁短连接，尤其在 VPS 环境下会放大上下文切换开销 -
failed parse elapsed time：非零值意味着大量 SQL 因语法错误、权限不足或对象不存在被拒绝，这类请求仍计入 DB Time，但不产生执行计划，会拉低整体效率 -
repeated bind elapsed time：Oracle 11g 新增，反映绑定变量重复使用带来的额外开销，若该值 > 1s 且伴随高library cache lock等待，说明存在大量相似 SQL（如 in-list 动态拼接）在争抢同一 cursor
为什么 Time Model 在 RAC 环境下更可靠
RAC 的 Top 5 Timed Events 是按实例聚合的，容易掩盖跨节点等待（比如一个实例等另一个实例的 gc buffer busy acquire）。而 Time Model 中的 sql execute elapsed time 和 DB CPU 是全局统计，只要看到某段时间内全局 sql execute elapsed time 暴涨但各实例 DB CPU 均不高，基本可断定是跨实例协调开销（如频繁 broadcast join 或序列争用）——这时候该查 GV$SQL 而不是单个 AWR 报告。
Time Model 不是万能的，但它强制你从“时间去哪了”这个最原始问题出发。很多人跳过这一步直接看 SQL 排序，结果优化了耗时长的 SQL，却发现 DB Time 没降——因为那条 SQL 其实只是“症状”，不是“病因”。
