真正反映I/O压力的是Av Rd(ms)与Phys Reads组合趋势：Av Rd(ms)>100ms且Phys Reads>5000/s可锁定I/O瓶颈；单看平均延迟易失真，需结合总量、文件级延迟及存储层指标综合判断。
Tablespace IO Stats里哪些指标真能反映I/O压力
看tablespace io stats不能只盯着av rd(ms)或av wr(ms)——这两个值是“平均”，但平均数在i/o场景下极易失真。真正要盯的是av rd(ms)是否持续超过20ms（oltp）或50ms（dss），以及phys reads和phys writes的突增是否与业务高峰吻合。
常见错误是把Av Rd(ms)从5ms跳到12ms就当成严重问题，其实得结合Reads总量：如果Phys Reads从1000/s降到200/s，平均延迟上升反而是负载下降的副产品。
- 重点关注
Av Rd(ms)+Phys Reads组合趋势，单看一个没意义 -
Av Wr(ms)对写密集型应用（如日志表、批量ETL）更关键，但Oracle默认异步写，所以该值常偏低，需配合Write Time（总毫秒）和Writes算出实际吞吐压力 -
Av Rd(ms)> 100ms且Phys Reads> 5000/s，基本可锁定为I/O瓶颈，不是SQL问题
数据文件级延迟为什么比表空间级更准
Tablespace IO Stats是聚合视图，同一表空间下多个数据文件的延迟被平均掉了。比如一个表空间含3个文件：users01.dbf（SSD，延迟2ms）、users02.dbf（老SAS盘，延迟85ms）、users03.dbf（故障盘假死，延迟2000ms），平均下来Av Rd(ms)可能才70ms，掩盖了真实热点。
必须下钻到File IO Stats（AWR报告第9部分）查单个file name，尤其注意Av Rd(ms)列和Av Rd(ms)标准差大的文件。
- 用
SELECT name, phyrds, readtim FROM v$filestat NATURAL JOIN v$dbfile实时验证AWR快照外的瞬时毛刺 - Linux下用
iostat -x 1比对%util和await，若await高但%util低，说明是存储队列或阵列卡问题，非数据库层可调 - Oracle 12c+可用
V$IOSTAT_FILE查每个文件的SMALL_READ_MILLIS，比AWR更细粒度
Av Rd(ms)突然飙升但iostat正常？先查这三处
AWR里Av Rd(ms)翻倍，而主机iostat显示await和%util平稳——大概率不是物理I/O慢，而是Oracle内部等待放大了延迟感知。
典型诱因是Buffer Cache争用或I/O路径异常，而非磁盘本身。这时Av Rd(ms)成了“症状指示器”，不是病因。
- 检查
DB CPU和latch: cache buffers chains等待是否同步上涨，高CPU会拖慢I/O完成回调，虚增Av Rd(ms) - 确认
db_file_multiblock_read_count是否被临时调小，导致同量数据读取次数变多，每次读的延迟被重复计入统计 - 查
V$SESSION_IO中CONSISTENT GETS与PHYSICAL READS比值，若骤降（比如从10:1变成2:1），说明一致性读大量退化为物理读，Av Rd(ms)自然被拉高
延迟高但读写量不大？小心ASM或存储层重试
当Phys Reads Av Rd(ms)却稳定在150ms以上，且iostat无异常——大概率是底层设备在静默重试。常见于ASM磁盘组中某块盘开始掉速，ASM自动切换路径并重发I/O，每次重试叠加超时时间，但主机I/O计数器不体现重试次数。
这种延迟不会触发iostat的await报警，因为OS看到的只是“一次完成”，而Oracle统计的是“从发出到回调”的全周期。
- 查
V$ASM_DISK的STATE和OFFLINE_DISKS，重点关注HEADER_STATUS为PROVISIONED但MODE_STATUS为ONLINE的盘——这是ASM已识别异常但尚未踢出的灰色状态 - 在存储侧抓
smartctl -a /dev/sdX，重点看Reallocated_Sector_Ct和Current_Pending_Sector是否非零 - Oracle 19c+启用
_asm_disk_repair_time=3600后，这类盘会更快被标记为OFFLINE，避免长期拖慢整个磁盘组
延迟分析最麻烦的从来不是数字本身，而是数字背后那层看不见的重试、缓存失效或路径切换。AWR里的Av Rd(ms)永远是“数据库视角”的延迟，不是“硬件视角”的延迟——这个落差，得靠跨层比对才能填平。
