awr 中无“iops”字段，实际 iops 由 physical reads per sec 与 physical writes per sec 之和近似得出；需通过 dba_hist_snapshot 对齐快照、用 dba_hist_sysmetric_summary 取 average_value，并结合 dba_hist_active_sess_history 和 dba_hist_iostat_file 分析上下文与文件级瓶颈。
看 DBA_HIST_SYSMETRIC_SUMMARY 里 IOPS 对应的指标名是否正确
AWR 本身不直接存 “IOPS” 这个字段，它存的是底层 I/O 指标，比如 Physical Reads Per Sec 和 Physical Writes Per Sec。这两个加起来才是实际 IOPS（四舍五入后近似）。很多人搜 IOPS 却查不到，是因为 AWR 视图里根本没这个列名。
实操建议：
- 确认你要查的指标是
Physical Reads Per Sec（metric_name = 'Physical Reads Per Sec'）和Physical Writes Per Sec（metric_name = 'Physical Writes Per Sec'），它们在DBA_HIST_SYSMETRIC_SUMMARY中按分钟粒度聚合 - 别查
DBA_HIST_SYSSTAT的累计值再自己除时间——容易漏掉采样间隔跳变、快照缺失等问题 - 注意单位：这两个指标单位是“次/秒”，不是 KB/s 或 MB/s；如果要换算成吞吐量，需结合平均 IO 大小（查
avg_read_req_sz/avg_write_req_sz）
用 DBA_HIST_SNAPSHOT 对齐时间窗口再聚合
直接查单个快照的 Physical Reads Per Sec 值意义不大，因为它是该快照周期内平均每秒值，而周期长度可能不一致（比如默认 60 分钟，但有时因 DB hang 或手动调整会变成 30 或 120 分钟）。
实操建议：
- 先通过
DBA_HIST_SNAPSHOT获取目标时间段内连续的快照 ID 范围（begin_interval_time/end_interval_time） - 用这些快照 ID 关联
DBA_HIST_SYSMETRIC_SUMMARY，过滤metric_name IN ('Physical Reads Per Sec', 'Physical Writes Per Sec') - 对每个快照取
average_value（不是maxval或minval），再按小时或业务时段做中位数/95分位统计，比看单点峰值更稳
对比基线时必须排除归档、RMAN、备份等干扰 IO
一个 2000 IOPS 的值，在 OLTP 时段算异常；但在 RMAN 备份期间可能只是 baseline 的 1.2 倍——不算异常。AWR 不自动标记 IO 来源，全靠你人工识别上下文。
实操建议：
- 查
DBA_HIST_ACTIVE_SESS_HISTORY，在高 IOPS 时间段内筛选event含db file scattered read、direct path read、backup sync I/O等关键词的会话 - 关联
sql_id查对应 SQL，看是否是已知的大表扫描、索引重建或 expdp 导出任务 - 检查
v$backup_set和v$rman_backup_job_details是否有重叠时间段的备份作业
DBA_HIST_IOSTAT_FILE 能定位到具体文件级瓶颈
系统级 IOPS 正常，不代表没问题。可能某几个数据文件持续满负荷（比如 temp 表空间或某个大索引所在文件），而其他文件很闲——这时整体 IOPS 看着还行，但应用已卡顿。
实操建议：
- 查
DBA_HIST_IOSTAT_FILE，重点关注small_read_reqs、small_write_reqs（对应随机 IO）、large_read_reqs（对应顺序 IO）三列，按文件名分组求和 - 对比同一文件在不同快照间的增量变化率，比绝对值更有参考性（例如某文件本周每小时平均
small_read_reqs比上周同段高 300%，即使总 IOPS 没涨也得查） - 注意
file_type_name是TEMPFILE还是DATAFILE：temp 文件暴增通常意味着大量排序或 hash join 溢出，未必是存储问题
