AWR报告中“I/O Profile”的Physical Reads/Writes Per Sec是数据库层IOPS，需结合db_block_size换算吞吐量，真实MB/s应看Physical Read/Write Total Bytes Per Sec；IOPS高不等于磁盘忙，须结合等待事件平均延迟、表空间IO统计及iostat交叉验证。
直接看AWR报告里的“I/O Profile”节，别跳过单位换算
AWR报告中“I/O Profile”部分给出的 Physical Reads Per Sec 和 Physical Writes Per Sec 就是数据库层的IOPS，但注意：它默认按Oracle db_block_size（如8KB或16KB）计数，不是操作系统块大小。比如 db_block_size=16K 时，1次物理读 = 16KB，那报告里显示的 1000 reads/sec 实际对应 15.6MB/s 吞吐量（1000 × 16 / 1024），而不是你直觉的1MB/s。
吞吐量指标 Physical Read Total Bytes Per Sec 才是真实MB/s值，可直接和存储厂商标称吞吐对比。常见误判是只盯着IOPS高就断定磁盘忙——如果单次读写块很大（如LOB direct path），IOPS可能不高但吞吐已打满。
- 查当前库块大小：
SELECT value FROM v$parameter WHERE name = 'db_block_size' - 若报告中 reads/sec 达 8000 但
db_block_size=8192，理论吞吐上限约 62.5MB/s；若实测Physical Read Total Bytes Per Sec接近 200MB/s，说明存在大量多块读（scattered read）或direct path，需下钻等待事件 - AWR不区分读写块来源（buffer cache miss还是direct path），所以IOPS数值是“混合型”的，不能直接等同于底层磁盘IOPS
用DBA_HIST_SYSTEM_EVENT定位IO类等待事件的真实延迟
单纯看IOPS和吞吐数字，无法判断是不是磁盘慢。真正反映IO响应质量的是三类核心等待事件的平均等待时间（AVERAGE_WAIT）：
-
db file sequential read：单块随机读，正常应 ≤ 10ms；持续 > 15ms 表明随机IO路径有瓶颈（如机械盘寻道、ASM rebalance、存储队列深） -
db file scattered read：多块顺序读，对SSD/全闪阵列，> 5ms 就值得警惕；传统盘可容忍稍高，但若伴随高IOPS且吞吐未提升，大概率是IO调度或文件系统层问题 -
direct path read：绕过Buffer Cache的大块读，常见于并行查询、大表排序、LOB操作；> 20ms 往往指向存储带宽争用或OS层预读失效
关键点：不要只取平均值。用如下SQL查尖峰时段：
SELECT s.snap_id, TO_CHAR(s.begin_interval_time,'HH24:MI') snap_time,
e.event_name, ROUND(e.time_waited_micro/1000/e.total_waits, 2) avg_ms,
e.total_waits
FROM dba_hist_system_event e
JOIN dba_hist_snapshot s ON e.snap_id = s.snap_id AND e.dbid = s.dbid
WHERE e.event_name IN ('db file sequential read','db file scattered read','direct path read')
AND e.total_waits > 0
AND s.begin_interval_time >= SYSDATE - 1
ORDER BY avg_ms DESC FETCH FIRST 10 ROWS ONLY;
若某次快照中 db file sequential read avg_ms 突然跳到 32ms，而同期 iostat 的 await 仅 8ms，说明问题不在磁盘本身，可能是热块争用或Latch竞争。
结合Tablespace IO Stats识别热点表空间与文件
AWR报告末尾的“Tablespace IO Stats”节列出每个表空间的IO统计，重点看两列：
-
Av Rd(ms)：该表空间所有数据文件平均读延迟。若某表空间明显高于其他（如 25ms vs 其他 6ms），先检查其对应文件是否落在同一LUN或RAID组上 -
Av Blks/Rd：平均每次读取的块数。值低（≈1）说明大量索引查找；值高（>10）说明全表扫描或direct path，此时要同步看“SQL ordered by Physical Reads”里是否含/*+ FULL() */或DBMS_LOB
特别注意LOB表空间：它的 Av Rd(ms) 高，往往不是磁盘问题，而是LOB CHUNK大小与实际访问粒度不匹配。例如 CHUNK=8KB，但应用每次读1MB CLOB，AWR会记为128次 direct path read，看似IOPS爆炸，实则是应用层加载策略不合理。
定位具体文件：查 DBA_HIST_IOSTAT_FILE 视图，过滤出 file# 对应的 small_read_mbps 和 large_read_mbps，比报告更细粒度。
别把AWR IOPS当最终结论，必须交叉验证操作系统层数据
AWR的IOPS是数据库视角的逻辑I/O计数，受Buffer Cache、Direct Path、ASM条带、多路径等多层影响。生产环境排查瓶颈时，必须拿 iostat -dx 2 的 r/s + w/s 和 rkB/s + wkB/s 对齐：
- 若AWR报告IOPS为 12000，而
iostat显示磁盘总IOPS仅 8500，差值大概率是ASM镜像写、归档日志、RMAN备份等非业务IO占用了资源 - 若AWR吞吐为 180MB/s，
iostat的rkB/s + wkB/s却只有 90MB/s，说明一半IO被Cache拦截（Physical Reads≠Logical Reads），此时真正压存储的是另一半 - RAC环境下，还要看
Global Cache相关等待（如gc cr block busy），它会导致节点间块传输，表现为AWR里IOPS虚高但实际磁盘IO不高
最易忽略的一点：AWR默认快照间隔1小时，而IO抖动常发生在秒级。如果问题只持续几分钟，AWR平均值会严重稀释异常，必须配合 ASH（V$ACTIVE_SESSION_HISTORY）查 sample_time 粒度的IO等待堆栈。
