Oracle数据库如何分析db file scattered read等待-Oracle-PHP中文网

若db file scattered read出现在awr报告top 5 timed events前三且avg wait ms超10ms，表明存在性能瓶颈，需先确认是否由非必要全表扫描引起，再结合wait time(s)与avg wait(ms)分析i/o效率、存储响应及碎片化问题。

oracle数据库如何分析db file scattered read等待

直接看 AWR 报告里的 Top 5 Timed Events

如果 db file scattered read 出现在 AWR 报告的 “Top 5 Timed Events” 前三位，尤其是平均等待时间（Avg Wait ms）超过 10ms，说明这不是正常物理读，而是性能瓶颈信号。别急着调参数，先确认它是不是由非必要全表扫描引起的。

关键看两个字段：Wait Time(s) 和 Avg Wait(ms)。前者反映总耗时，后者反映单次 I/O 效率。若总耗时高但平均等待短（比如 20ms），要怀疑存储响应慢或碎片化严重。

AWR 时间窗口必须覆盖业务高峰期，不能选备份或空闲时段
注意区分实例：RAC 环境下，Instance Number 必须对得上，否则会混入其他节点噪声
跳过数据字典查询（如 select * from v$xxx），它们天然带全表扫描，不具优化价值

查出真正触发 scattered read 的 SQL

不是所有全表扫描都该被干掉，但得知道是谁在扫、扫什么、为什么扫。核心路径是：从等待事件反推 SQL，再看执行计划是否合理。

用以下语句定位当前活跃会话中正在等 db file scattered read 的 SQL：

SELECT s.sid, s.sql_id, s.event, s.p1 "File#", s.p2 "Block#", s.p3 "Blocks"
FROM v$session s
WHERE s.event = 'db file scattered read'
AND s.state = 'WAITING';

拿到 sql_id 后，查执行计划：

oracle知识库

oracle知识库下载

下载

SELECT * FROM v$sql_plan WHERE sql_id = '<your_sql_id>' AND operation LIKE '%TABLE ACCESS%' AND options = 'FULL';</your_sql_id>

如果 OBJECT_NAME 是大表（比如 >100MB），且没走索引，优先检查缺失统计信息：DBMS_STATS.GATHER_TABLE_STATS
如果走的是 INDEX FAST FULL SCAN，说明索引本身被当“表”用了，可能是因为查询只涉及索引列但没加 WHERE 条件，或索引选择性极差
注意 PARTITION_START/PARTITION_STOP 字段：如果是分区表但没做分区裁剪（显示 ROW LOCATION 或 ALL），说明分区键没进 WHERE，白扫一整块

别盲目调 DB_FILE_MULTIBLOCK_READ_COUNT

这个参数控制每次多块读的块数，默认值在 10gR2+ 已自动适配系统最大 I/O 能力（通常对应 1MB）。手动调高可能反而降低效率：

设太大（如 128 块 × 8KB = 1MB），但存储底层 max I/O size 只支持 512KB，会导致 I/O 拆分，增加系统调用开销
设太小（如 8），I/O 次数暴增，CPU 在发起请求上浪费更多时间
不同平台默认值不同：Linux x86-64 通常是 128，AIX 可能是 64 —— 查当前值用：SHOW PARAMETER db_file_multiblock_read_count

真正该调的是底层 I/O 能力：确保文件系统挂载选项含 noatime，ASM diskgroup 的 ALLOCATION UNIT SIZE 与 DB_BLOCK_SIZE 对齐，LUN 划分足够分散（避免热点盘）。

关注 Buffer Cache 替换策略和 KEEP 池误用

db file scattered read 读进来的块默认放在 LRU 链表冷端，很快被挤出。如果某张报表天天被全扫，却总被刷掉，下次还得重读 —— 这不是 SQL 问题，是缓存策略问题。

别轻易把大表塞进 KEEP 池：KEEP 池空间有限，一旦溢出，反而加剧 free buffer waits
更稳妥的做法是用 ALTER TABLE ... CACHE（仅适用于小表或访问模式高度可预测的中表）
观察 v$bh 中该对象的 STATUS 分布：如果大量块状态为 xcur 或 cr 但 TCH（touch count）长期为 0，说明根本没被复用，缓存无意义

真正难处理的，是那些“半热”表：每天扫一次，每次耗时 2 分钟，既不够热到常驻内存，又不够冷到接受慢速磁盘读 —— 这类必须靠 SQL 改写或物化视图固化结果，而不是调 I/O 参数。