应重点检查tablespace io stats中reads和av rd(ms)是否失衡：若某表空间reads超其他5倍且av rd(ms)>15ms，大概率存在io倾斜；需用v$filestat下钻定位物理文件热点，并注意readtim需×10换算为毫秒；asm环境须直查v$asm_disk_iostat。
看 Tablespace IO Stats 里 Reads 和 Av Rd(ms) 的分布是否失衡
AWR 报告中 Tablespace IO Stats 表格是第一眼要盯的地方，但别只扫“总读数”——重点看两列：Reads 和 Av Rd(ms)。如果某个表空间的 Reads 是其他表空间的 5 倍以上，且 Av Rd(ms) 同时明显偏高（比如 >15 ms），大概率不是负载均衡问题，而是 IO 倾斜：数据文件物理分布不均，或该表空间下某些数据文件被高频访问。
常见陷阱：
-
Av Rd(ms)是加权平均值，一个慢盘可能被大量快盘拉低，掩盖真实倾斜 - UNDOTBS、TEMP 这类系统表空间天然读写集中，不能直接对标业务表空间
- ICCIDAT01 这类业务表空间若
Av Rd(ms)突然从 3.76 ms 涨到 22.4 ms，而Reads只增 10%，说明不是量大，而是单次读变慢 → 往磁盘层查
用 v$filestat 定位具体数据文件的 IO 热点
Tablespace IO Stats 只给逻辑层聚合，真要确认倾斜，必须下钻到物理文件。执行以下查询：
SELECT d.name, f.phyrds, f.phyblkrd, f.readtim,
ROUND(f.readtim / NULLIF(f.phyrds, 0) * 10, 2) AS avg_read_ms
FROM v$filestat f, v$datafile d
WHERE f.file# = d.file#
AND f.phyrds > 0
ORDER BY f.phyrds DESC;
关键点：
-
readtim单位是厘秒（centiseconds），乘以 10 才是毫秒 —— 漏换算会误判 10 倍延迟 - 同一表空间内，若某文件
avg_read_ms是其他文件的 3 倍以上，且phyrds也显著更高，就是倾斜源 - 注意文件路径：/u01/oradata/DB/ICCIDAT01_03.dbf 如果和 /u01/oradata/DB/ICCIDAT01_01.dbf 在同一物理磁盘，那不是倾斜，是磁盘瓶颈
结合 db file sequential read 等待事件交叉验证
IO 倾斜常表现为等待事件异常聚集。在 AWR 的 Top 5 Timed Events 中，如果 db file sequential read 占比 >20% 且 Av Rd(ms) >15 ms，再查 SQL ordered by Physical Reads 是否集中在某几个 SQL 上 —— 这些 SQL 访问的表/索引，大概率落在倾斜的数据文件里。
更隐蔽的情况：
- 这些 SQL 执行计划没变，但
CLUSTERING_FACTOR未恶化，Buffer Hit %却掉 10% → 说明缓存失效加剧，根源可能是某几块盘响应慢，导致预读失败、物理读被迫重发 - 对比正常时段报告，若
physical read IO requests增幅远超physical reads（例如 +70% vs +15%），说明 I/O 请求被打散 → 典型碎片+倾斜共现
ASM 环境下必须跳过 Tablespace IO Stats，直查 v$asm_disk_iostat
如果你用 ASM，Tablespace IO Stats 几乎无用：一个表空间的数据文件可能跨多个磁盘组，甚至同一磁盘组内不同磁盘的负载完全不对等。此时必须查：
SELECT group_number, disk_number,
ROUND((read_time/reads)*10,2) avg_read_ms,
read_errs, percent_soft_reads
FROM v$asm_disk_iostat
WHERE reads > 0
ORDER BY avg_read_ms DESC;
真正要警惕的是：
- 同一磁盘组内，某盘
avg_read_ms>50 ms（OLTP 场景），其余都 -
percent_soft_readsread_errs = 0 → 不是硬件问题，是_asm_cache_size设置过小或热点未缓存 - 查
v$asm_disk确认HEADER_STATUS是PROVISIONED而非MEMBER→ 那块盘已被 ASM 主动隔离，但旧数据还在上面跑
复杂点在于：IO 倾斜未必是存储配置问题，更可能是应用访问模式（比如某张分区表只查最新分区，而该分区恰好落在某几块盘上）。不结合 SQL 访问路径和 ASM 磁盘映射关系，光看数字容易误判。
