若 direct path read 在 top 5 中排名靠前、等待时间占比＞15%且平均等待＞10ms，结合 physical reads/sec 与 logical reads/sec 比值突增、buffer hit % 下降超5%、sql 出现 table access full 且 physical reads per exec＞10000，可判定存在非预期全表扫描。
看 Top 5 Timed Foreground Events 里 direct path read 是否异常突出
全表扫描在 Oracle 中常触发 direct path read 等待事件，它不走 Buffer Cache，直接从磁盘读块，是典型的大批量物理 I/O 行为。如果该事件在 Top 5 中排第一或第二，且等待总时间占比高（比如 >15%）、平均等待时间也偏高（>10ms），基本可判定存在非预期的全表扫描。
- 注意区分正常场景：报表类 SQL、ETL 加载、首次冷启动查询等本就该走 direct path，不能单凭出现就报警
- 关键看“突变”：对比前一周期 AWR 报告，若
direct path read的 Wait Time 或次数增长超过 2 倍，而业务逻辑没变，就要怀疑 SQL 执行计划退化 - RAC 环境下需核对 Instance ID —— 某节点上
direct path read骤增，可能是本地大表扫描，未必是全局问题
查 SQL ordered by Physical Reads 中是否集中出现 TABLE ACCESS FULL
这一节列出物理读最多的 SQL，不是看谁“总读得多”，而是看谁“单次读得离谱”且执行计划不合理。重点过滤出 Operation 列为 TABLE ACCESS FULL 的行，并交叉验证：
- 检查对应 SQL 的
Executions和Physical Reads Per Exec：若后者 >10000，且表行数不大（比如 - 用
DBA_HIST_SQL_PLAN回溯历史执行计划：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id'))，确认是否近期才从INDEX RANGE SCAN退化为全表扫描 - 留意 WHERE 条件字段是否有统计信息陈旧（
LAST_ANALYZED超过 7 天）、数据倾斜（HISTOGRAM缺失）或绑定变量窥探失效
结合 Tablespace IO Stats 判断是否因碎片加剧了全表扫描开销
全表扫描本身不等于性能差，但若底层表空间碎片严重，会导致 physical read IO requests 显著高于 physical reads，即同样读 1000 块，却发出了 3000+ 次 I/O 请求——这是磁头寻道放大，会拖慢扫描速度。
- 在 “Tablespace IO Stats” 小节中，计算比值：
physical read IO requests / physical reads；正常应接近 1.x（比如 1.2~1.5），若 >2.0 且集中在某表空间，说明该空间块离散度高 - 同步查看该表空间的
Avg I/O Elapsed Time是否明显高于其他表空间（如高出 50% 以上），佐证 I/O 效率恶化 - 特别关注那些被
SQL ordered by Physical Reads点名、又落在高碎片表空间里的大表——它们才是全表扫描真正卡顿的根源
别漏掉 Load Profile 里 Physical Reads/sec 和 Logical Reads/sec 的比值变化
这个比值（Physical Reads/sec ÷ Logical Reads/sec）能绕过 SQL 粒度，反映整体缓存效率是否被全表扫描冲垮。比值突然升高（比如从 0.05 升到 0.3），往往意味着大量新数据涌入，Buffer Cache 来不及缓存，被迫反复物理读。
- 若比值升高的同时，
Buffer Hit %下降超 5%，且db block gets和consistent gets并未同比例增长，基本锁定是全表扫描导致 cache churn - 此时再回看 “SQL ordered by Gets” —— 如果 top SQL 的
Logical Reads Per Exec很低，但Physical Reads Per Exec极高，就是典型的“扫完就扔、不复用”的低效模式 - 注意：该比值稳定甚至下降，但
direct path read却飙升，可能说明系统正在做大批量直读（如并行插入），不一定是坏信号
真正难识别的，是那些只在特定参数组合下才走全表扫描的 SQL——比如 WHERE status = :1，当 :1 = 'PENDING' 时返回 95% 行数，优化器自然选全表；但报告里只看到一条 SQL，不会自动告诉你这个谓词的选择性有多差。必须把执行计划、列统计信息、实际返回行数三者串起来看，缺一不可。
