awr中db file scattered read占比高不等于数据库慢，仅当其占总等待超30%且av blks/rd长期低于4时才需干预；须通过v$sql_plan定位全表扫描sql、结合awr报告与10046 trace分析根本原因，而非盲目调参。
AWR 中 db file scattered read 占比高，不等于数据库慢；只有当它在 Top 5 Wait Events 中持续靠前、且 Av Blks/Rd 长期低于 4 时，才说明多块读效率异常，需定位真实瓶颈——不是调参，而是查 SQL、查对象、查存储。
怎么确认是不是真有问题
别只看 AWR 里“db file scattered read”总等待时间高。重点看三个交叉指标：
-
Av Blks/Rd（File I/O Statistics 表中）长期 ≤ 4：说明每次多块读实际读的块数太少，MBRC 参数没起效 - 该事件占总等待时间 > 30%：单个事件主导了 I/O 等待，不是偶发抖动
- 对应 SQL 的
buffer_gets和disk_reads比值持续走低（比如从 20:1 掉到 3:1）：缓存命中率塌方，物理读暴增
如果只是 db file scattered read 时间长但 Av Blks/Rd 稳定在 64～128，大概率是报表类 SQL 正常全扫，不用动。
如何快速定位触发它的 SQL 和表
用 AWR 报告 + 动态视图双验证，避免只查 v$session_event 被会话生命周期干扰：
- 查 AWR “SQL ordered by Reads”：找
disk_reads高、executions低的语句——典型夜间 ETL 或导出 SQL - 查当前活跃全扫：
SELECT sql_id, sql_text FROM v$sqltext t JOIN v$sql_plan p ON t.sql_id = p.sql_id WHERE p.operation = 'TABLE ACCESS' AND p.options = 'FULL' ORDER BY t.piece - 查是否误伤索引：
SELECT sql_id, sql_text FROM v$sql_plan p JOIN v$sqltext t ON p.sql_id = t.sql_id WHERE p.operation = 'INDEX' AND p.options = 'FULL SCAN'（INDEX FAST FULL SCAN同样触发该等待）
注意：current_obj# 在 v$active_session_history 中指向真实被读的段，可能和执行计划里写的表名不一致（比如读的是索引段而非表段）。
为什么加了索引或调了 DB_FILE_MULTIBLOCK_READ_COUNT 还没用
常见失效场景和对应验证动作：
- 索引建了但统计信息过期：
DBMS_STATS.GATHER_TABLE_STATS没跑 → 查DBA_TAB_STATISTICS.LAST_ANALYZED是否在迁移/大导入后未更新 - 索引字段顺序错位：WHERE dept_id = ? AND salary > ?，却建了
(salary, dept_id)→ 执行计划里INDEX RANGE SCAN的Access Predicates是否为空 - MBRC 设成 128，但 trace 里
p3值始终是 16 → 存储层 extent 太小（如 8 块）或 buffer cache 已缓存部分块，导致 Oracle 拆成多次 I/O - 表有大量行迁移：
DBA_TABLES.CHAIN_CNT> 0.5% → 回表时强制触发db file sequential read，把本该多块读的全表扫描“打碎”
真实 MBRC 效能必须看 10046 trace 中 WAIT ... p3=XX 的众数，不是参数值。
最容易被忽略的底层信号
当所有 SQL 和索引都看似合理，但 Av Blks/Rd 就是上不去，立刻下钻到文件级 I/O：
- 查 AWR “File I/O Statistics” 表：哪些数据文件的
Av I/O Wait (ms)突增（SSD > 5ms、HDD > 15ms 且持续 >30 分钟） - 用
iostat -x 1对应 ASM diskgroup 或底层 LUN，看%util和await是否饱和 - 对比迁移前后 AWR：若
Physical Reads Per Second不变，但Av I/O Wait升高 → 存储链路延迟升高，和数据库配置无关
这时候再调 DB_FILE_MULTIBLOCK_READ_COUNT，只是把问题从“读得慢”变成“读得更慢”。
