必须盯死0–1ms区间占比骤降、16–32ms与32–64ms区间同步激增超2倍、以及4秒至2分钟区间中db file sequential read出现（哪怕仅0.3%），这三处是IO物理瓶颈最直接证据。
盯死Wait Event Histogram里的三个关键区间
awr报告里wait event histogram不是辅助项，它是io是否已到物理瓶颈的最直接证据——比db file sequential read平均等待毫秒数更早暴露问题。
-
0–1 ms区间占比骤降（比如从75%跌到40%）：说明I/O开始排队，不再是“发完就回”，而是卡在OS或存储队列里等调度 -
16–32 ms与32–64 ms区间计数同步激增超2倍，且与db file parallel write共现：基本可断定磁盘响应跟不上并发写入节奏 -
Wait Event Histogram Detail (4 sec to 2 min)中出现db file sequential read（哪怕仅占0.3%）：代表有会话单次读卡了4秒以上——这绝不是SQL或缓存问题，是存储链路或HBA队列深度严重不足
别信Av Rd(ms)，要看File IO Stats里单个文件的延迟分布
Av Rd(ms)是加权平均值，会被大量短延时I/O拉低。90%的读在2ms内完成、剩下10%卡在80ms，平均可能才8ms——看起来完全OK，但那10%的毛刺会直接拖垮OLTP事务。
- 下钻到
File IO Stats部分，按Av I/O Wait (ms)排序，找出平均等待超10ms的数据文件（SSD环境超5ms就该警惕） - 结合
Physical Reads和Av I/O Wait交叉判断：读次数少但延迟极高 → 存储链路问题（如SAN路径拥塞）；读次数多且延迟高 → SQL或索引问题 - 用
dba_data_files查出高延迟文件对应表空间，再查dba_segments确认哪些表/索引被高频访问
ASM环境下必须跳过Tablespace IO Stats，直查v$asm_disk_iostat
Tablespace IO Stats对ASM诊断基本无效：它按表空间聚合，而ASM磁盘组是底层抽象层，一个表空间的数据文件可能跨多个磁盘甚至多个磁盘组；它的Av Rd(ms)会掩盖单个慢盘（比如某块SSD故障后延迟飙到2000ms，但被其他盘拉低到50ms）。
- 查
v$asm_disk_iostat，字段单位是厘秒，算毫秒延迟：ROUND((read_time/reads)*10,2) - 持续
avg_read_ms > 20（OLTP）或> 50（DSS）即需干预 -
READ_ERRS > 0或WRITE_ERRS > 0：立刻检查HEADER_STATUS是否为PROVISIONED或FAILED - 云/虚拟化环境（如AWS EBS gp3）必须用
v$asm_disk_iostat_sparse，它暴露READ_TIME_WAIT，能区分是ASM处理慢还是后端存储卡住
用Load Profile和Instance Efficiency交叉验证真伪IO瓶颈
高db file sequential read不等于真实IO瓶颈——可能是SQL没走索引、内存太小或统计信息过期。必须先排除这些“假IO”。
-
Physical Reads Per Second持续超2000，且Logical Reads Per Second不高 → 真实IO压力大 Buffer Hit Ratio → 先查<code>db_cache_size是否够，或是否存在热点块争用（看latch: cache buffers chains是否同步升高）-
Redo Size Per Second翻倍同时Physical Reads飙升 → 很可能是应用层批量提交导致日志写压力传导到数据文件IO -
%util接近100%、await远高于svctm→ OS层面已确认存储饱和
4 sec to 2 min区间的任何非零值，都意味着存储链路存在不可接受的长尾延迟——这不是调优能解决的问题，必须从硬件或驱动层介入。
