DBA_HIST_SYSMETRIC_HISTORY 中 'Average Read Time (ms)' 字段（VALUE）存储每15秒采样的真实Avg Rd(ms)值，带时间戳且对应具体采样点，需过滤NULL并关联SNAPSHOT获取时间，用于精准定位I/O延迟。
查 DBA_HIST_SYSMETRIC_HISTORY 里真实的 Avg Rd(ms) 值
awr 报告里看到的 “i/o response time – avg rd(ms)” 是聚合统计值，不带时间戳、不区分设备、也不对应具体采样点。真要定位哪次采样超了 10ms，得挖底层视图。dba_hist_sysmetric_history 每 15 秒存一次 i/o 响应时间（单位毫秒），字段叫 value，指标名是 'average read time (ms)'。
- 别用
DBA_HIST_SNAPSHOT或DBA_HIST_SYSTEM_EVENT查这个值——前者没响应时间字段，后者给的是等待事件总耗时，不是单次读的平均值 - 注意
VALUE是浮点数，可能为NULL（比如没发生物理读），过滤时加VALUE IS NOT NULL - 查询示例：
SELECT TO_CHAR(sn.BEGIN_INTERVAL_TIME, 'yyyy-mm-dd hh24:mi') tm,<br> m.VALUE<br>FROM DBA_HIST_SYSMETRIC_HISTORY m<br>JOIN DBA_HIST_SNAPSHOT sn ON m.SNAP_ID = sn.SNAP_ID AND m.DBID = sn.DBID<br>WHERE m.METRIC_NAME = 'Average Read Time (ms)'<br> AND m.VALUE > 10<br>ORDER BY sn.BEGIN_INTERVAL_TIME DESC;
确认是不是存储层问题，还是数据库自身干扰
Avg Rd(ms) > 10ms 不等于存储慢。Oracle 把所有物理读都算进去，包括闪回日志读、归档日志读、甚至临时段读——这些未必走生产存储阵列。
- 先看
V$IOSTAT_FUNCTION，重点关注FUNCTION_NAME为'DBWR'、'ARCH'、'RMAN BACKUP'的行，它们的AVG_READ_TIME_MS高，说明是后台进程在拖慢平均值 - 如果
V$IOSTAT_FILE里FILE_TYPE是'Log File'或'Archive Log'的AVG_READ_TIME_MS显著偏高，大概率和主库 IO 路径无关 - 真正反映 OLTP 随机读延迟的，是
V$IOSTAT_FILE中FILE_TYPE = 'Data File'且SMALL_READ_REQS高的那些文件
AWR 报告中 “I/O Response Time” 数值为什么经常比监控工具低
因为 AWR 默认只统计“完成的 I/O”，而很多存储性能工具（如 iostat -x、zpool iostat）统计的是发出但未返回的 I/O 队列深度 + 实际服务时间，两者口径不一致。
-
DBA_HIST_SYSMETRIC_HISTORY的'Average Read Time (ms)'是对V$SYSMETRIC的采样，本质仍是数据库视角：从发起pread()到收到内核返回的时间，不含存储队列等待 - 如果存储阵列本身有写缓存、读预取或 QoS 限速，AWR 看不到排队时间，但
iostat的%util或await会飙升 - 验证方法：在同一时段抓
iostat -x 1，对比r_await和 AWR 里的Avg Rd(ms)；若前者稳定在 8–9ms、后者常超 15ms，说明 Oracle 内部有争用（比如 buffer busy waits 导致重试读）
设置告警时别只盯单个阈值
10ms 是常见经验值，但实际要看趋势和分布。连续 3 次采样 >10ms 和偶发一次 18ms，风险等级差很远。
- 用
STDDEV和COUNT(*)辅助判断：同一小时内STDDEV(VALUE)> 5 且COUNT(*) FILTER (WHERE VALUE > 10)≥ 5，才值得触发告警 - 避免在备份窗口、统计信息收集时段告警——这些时段
FUNCTION_NAME为'RMAN BACKUP'或'GATHER_STATS_JOB'的 I/O 占比突增，拉高均值但无业务影响 - 真正该警惕的是
DBA_HIST_SYSMETRIC_HISTORY中'Average Read Time (ms)'和'Average Write Time (ms)'同时持续 >10ms，且V$IOSTAT_FUNCTION中'User I/O'类型占比 >70%
