elapsed time 为0或极小值是快照间隔过短所致，表明所选起止快照时间相同或仅差几秒；其值偏大则源于系统时钟漂移、ntp校正或虚拟机暂停等os层因素，并非数据库异常。
Elapsed Time 不会“异常”，它只是快照间隔的物理时长——如果看到它数值离谱，一定是你没看懂报告结构或选错了快照
为什么 Elapsed Time 显示为 0 或极小值（如 0.01 分钟）
这是最常被误读的“异常”。Elapsed Time 是两次 AWR 快照之间的真实挂钟时间，不是数据库运行时间。它为 0 或极小，只说明你选的两个快照 ID 是同一时刻、或间隔太短（比如手动频繁打快照），导致采样窗口几乎为零。
- 检查
Begin Snap和End Snap对应的Snap Time：若两者相同或仅差几秒，Elapsed Time必然趋近于 0 - AWR 默认每小时打一次快照（
snapshot_interval= 60），但 DBA 可能临时执行DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动补采——这种快照容易造成“伪异常” - 不要用
Elapsed Time = 0去算 AAS（Average Active Sessions），此时分母为零，结果无意义
为什么 Elapsed Time 比预期长很多（比如标称 60 分钟，实际显示 72.5 分钟）
AWR 的 Elapsed Time 是操作系统级计时，受系统时钟漂移、NTP 调整、虚拟机暂停等外部因素影响，并非 Oracle 自身误差。
- 在虚拟化环境（如 VMware、OCI）中，宿主机 CPU 抢占或 vCPU 暂停会导致 guest OS 时间跳变，
Elapsed Time可能比真实流逝时间多出数分钟 - 若服务器启用了 NTP 服务且发生大幅校正（如
ntpd -q强制同步），/proc/uptime 与 getrusage() 统计可能短暂失准，AWR 采集到的间隔就失真 - 对比
v$osstat中的ELAPSED_TIME_S和报告里写的Elapsed Time：若二者偏差 > 2%，基本可判定是 OS 层时间源问题，而非数据库故障
为什么 Elapsed Time 和 DB Time 的比值看起来不合理（比如 Elapsed=60min，DB Time=5min）
这不是 Elapsed Time 异常，而是负载极低的正常现象。DB Time 小 ≠ 数据库“空闲”，它只反映前台会话实际消耗的服务时间总和。
- 典型场景：夜间批处理已结束，只有几个后台 Job 在跑，无用户连接——此时
DB Time接近 0，Elapsed Time仍是 60 分钟 - 注意区分
DB Time和DB CPU：DB Time包含等待（如log file sync、db file sequential read），而DB CPU仅含真实 CPU 占用；低 DB Time 下若DB CPU占比反常高（如 >80%），才值得查是否某后台进程在死循环 - RAC 环境下，每个实例的 AWR 报告都独立计算
Elapsed Time，但 DBA 常误用全局 DB Time 除以单实例 Elapsed Time，得出虚假高并发结论
真正要警惕的不是 Elapsed Time 本身，而是它作为分母参与的指标（如 AAS、DB Time / Elapsed）是否与业务行为矛盾——比如交易高峰期 AAS = 0.3，那大概率是快照没覆盖到真实压力时段，或者应用根本没连上来。
