AWR中direct path read高不一定是LOB或大表扫描所致，需结合Av Rd(ms)>15ms、Block cnt大、SQL含DBMS_LOB等关键字确认LOB瓶颈；P1指向TEMP表空间则多为排序落盘，指向用户数据文件则倾向大表扫描或并行查询；索引无效、表设PARALLEL、_small_table_threshold触发或AUD$/RAC争用亦可导致该等待。
AWR里看到direct path read高，不等于就是LOB或大表扫描问题——它可能来自排序、并行查询、临时段读写，甚至审计表全扫，得先分清来源再动手。
怎么看direct path read是不是LOB引起的
LOB操作触发的direct path read有典型特征：等待时间长（Av Rd(ms) >15ms）、单次读块数多（Block cnt常达数百甚至上千），且SQL里带DBMS_LOB、READ、WRITE等关键字。
- 去AWR报告的「Top 5 Timed Events」确认
direct path read是否排前三，同时记下Av Rd(ms) - 翻到「Tablespace IO Stats」，定位LOB所在表空间（如
LOB_TBS），对比其Av Rd(ms)是否显著高于其他表空间 - 查「SQL ordered by Physical Reads」，用
DBMS_LOB或TO_CLOB等关键词过滤，命中即大概率是LOB瓶颈 - 注意：
Physical Reads总数低但direct path read高，说明是单次大块读（比如加载4MB CLOB），不是IOPS过载
怎么区分是排序还是全表扫描导致的
direct path read参数里的P1（file#）是关键线索：如果是TEMP表空间的文件号，基本可断定是排序落盘；如果是用户数据文件号，则更可能是大表扫描或并行查询。
- 执行
SELECT file_name FROM dba_data_files WHERE file_id = &P1;，确认P1对应文件归属 - 查
v$sort_segment和v$sysstat中workarea executions指标，若USED_BLOCKS持续增长，说明大量direct path read temp - 在「SQL ordered by Gets」里找含
ORDER BY、GROUP BY、UNION、HASH JOIN的SQL，结合执行计划看是否有Temp Space列值突增 -
serial_direct_read隐含参数设为never可强制禁用串行直读，但仅用于诊断，勿长期启用
为什么建了索引direct path read还在涨
索引本身不解决直读——如果SQL仍走全表扫描（比如谓词含!=、LIKE '%xxx'、函数索引未匹配），或表被设为PARALLEL，Oracle仍会启用直接路径读，绕过buffer cache。
- 检查执行计划是否真走了索引：
INDEX RANGE SCAN或INDEX UNIQUE SCAN才有效；FULL TABLE SCAN或PARTITION LIST ALL仍是直读温床 - 确认表级并行度：
SELECT degree FROM dba_tables WHERE table_name = 'XXX';，非零值会极大提高直读概率 - 查
v$active_session_history中该SQL的sql_plan_operation，若出现TABLE ACCESS STORAGE FULL，说明已启用存储层优化（如Exadata），但仍在直读 -
_small_table_threshold默认是buffer cache的2%，表大小超此阈值就倾向直读——哪怕加了索引，只要优化器判定全扫更快，依然直读
容易被忽略的RAC和AUD$陷阱
RAC环境下direct path read高，未必是IO慢，可能是GC争用；而AUD$这类系统表没索引+全扫，会把直读伪装成业务SQL问题。
- 查AWR中「Global Cache and Enqueue Statistics」节，若
gc cr block busy同步升高，且file#指向LOB索引段，说明多个节点在争同一LOB块 - 运行
SELECT segment_name, segment_type FROM dba_extents WHERE file_id = &P1 AND &P2 BETWEEN block_id AND block_id + blocks - 1;，确认P1/P2是否落在AUD$或FGA_LOG$上 - 审计SQL若含
!= 0、TO_CHAR(timestamp)等无法走索引的条件，物理读98%以上都可能来自它，而非业务表 -
direct path read和log file sync同时飙升时，先看磁盘利用率是否100%——直读只是表象，底层IO饱和才是根因
