不能只看Physical Reads总数，因其统计的是数据块数（blocks/s），而非实际I/O请求次数；真正反映并发IOPS压力的是Physical Read/Write Total IO Requests，结合Av Rd(ms)可识别随机小IO风暴或存储队列瓶颈。
直接看 Tablespace IO Stats 章节，按 Physical Read Total IO Requests 和 Physical Write Total IO Requests 降序排，前两名基本就是罪魁祸首。
为什么不能只看 Physical Reads 总数？
因为 Physical Reads 统计的是数据块数（单位：blocks/s），而 IOPS 是实际 I/O 请求次数。LOB、排序、并行查询等操作常走 direct path，一次读可能拉取 1MB，但只算 1 次 Physical Read Total IO Requests，却产生 128 次底层 OS I/O（假设 CHUNK=8KB）。AWR 中真正反映并发压力的是 Physical Read Total IO Requests 和 Physical Write Total IO Requests 这两项。
-
Physical Reads高但Physical Read Total IO Requests低 → 大块顺序读，未必压垮 IOPS -
Physical Read Total IO Requests高且Av Rd(ms)>10ms → 真正的随机小IO风暴，IOPS 瓶颈高概率在此 - RAC 环境下还要核对
gc cr block busy是否同步飙升——可能是 LOBINDEX 或热块争用导致假性 IOPS 上升
怎么快速定位到具体表空间？
打开 AWR 报告，跳转到 Tablespace IO Stats 表格，重点关注三列：
-
Phys Reads：物理读块数（参考数据量） -
Read Req：即Physical Read Total IO Requests（核心 IOPS 指标） -
Av Rd(ms)：平均单次读等待时间（判断是否真慢，还是只是忙）
排序时不要手动算总和，直接按 Read Req 列点击降序——USERS、LOB_TBS、SYS_AUX 这几个名字反复出现，基本不用往下翻了。
注意：SYSTEM 和 SYSAUX 表空间的 Read Req 异常高，大概率不是业务 SQL，而是统计信息收集、AWR 自身写入或日志归档触发的后台活动。
确认后下一步该查什么？
锁定高 IOPS 表空间后，别急着杀 SQL，先验证是不是“合法高频”：
- 去
SQL ordered by Physical Reads章节，过滤出SQL Text含DBMS_LOB、TO_LOB、INSERT /*+ APPEND */的语句——LOB 写入或直接路径加载是常见元凶 - 查
IOStat by Filetype：如果LOB data行的Read Req占比超 40%，基本坐实 LOB 存储设计问题 - 运行
SELECT tablespace_name, segment_type, COUNT(*) FROM dba_extents WHERE tablespace_name = 'XXX' GROUP BY tablespace_name, segment_type;——若LOBSEGMENT数量远超TABLE，说明应用大量使用大字段且未做裁剪
真正容易被忽略的是：IOPS 上限往往是存储阵列的队列深度或控制器处理能力限制，不是数据库本身瓶颈。AWR 能告诉你「谁在发请求」，但不能替代 iostat -x 1 或存储端的 LUN 级延迟分析。看到 Av Rd(ms) 突然从 2ms 拉到 25ms，第一反应不该是调 SQL，而是立刻去看存储队列等待和服务时间。
