直接查v$active_session_history中event='direct path read'不可靠，必须结合current_obj#、sql_id、sample_time>sysdate-1/48、session_type='foreground'及wait_time>10000微秒筛选高耗时样本，并关联dba_objects归因对象，才能准确定位拖慢系统的根本sql。
直接查 v$active_session_history 里 event = 'direct path read' 是错的——它只告诉你“正在读”，不告诉你“为什么慢”或“读的是什么”。必须结合 current_obj#、sql_id 和时间窗口做上下文归因，否则你会把归档备份、RMAN恢复、大表并行扫描全混在一起。
为什么 direct path read 等待高，但平均时间却不高？
常见现象是 AWR 或 ASH 显示 direct path read 等待次数多（比如每秒上千次），但 avg_wait_time 只有 1–2ms。这不是 I/O 快，而是 Oracle 在反复发起小块读（如 128KB），每次很快，但总量压垮了存储队列。典型场景包括：
- 并行查询中
degree > 1且未设parallel_degree_policy = 'AUTO'，导致大量 worker 进程各自发小 IO - 临时表空间不足，
hash join或sort溢出后走 direct path read temp，但 temp 表空间文件落在低性能 LUN 上 - RMAN 备份或 Data Pump 导出在运行，它们天然使用 direct path 读，但没被业务监控覆盖到
怎么定位真正拖慢系统的 direct path read SQL？
关键不是“谁在读”，而是“谁让系统等得最久”。要过滤掉短平快的读，聚焦高耗时样本：
- 限定
sample_time > SYSDATE - 1/48（最近 30 分钟），ASH 默认只保留约 60 分钟数据，太宽会命中已刷出内存的老样本 - 加
session_type = 'FOREGROUND'，排除 RMAN、Data Pump 等后台会话干扰 - 用
wait_time > 10000（单位微秒，即 >10ms）筛出真正卡顿的采样点，避免淹没在大量 sub-ms 样本里 - 关联
dba_objects补全对象名：WHERE a.current_obj# > 0 AND o.object_id(+) = a.current_obj#，否则current_obj#为 0 时无法归因到表或索引
示例语句：
SELECT a.sql_id, o.object_name, a.event, COUNT(*) cnt FROM v$active_session_history a LEFT JOIN dba_objects o ON o.object_id = a.current_obj# WHERE a.event = 'direct path read' AND a.sample_time > SYSDATE - 1/48 AND a.session_type = 'FOREGROUND' AND a.wait_time > 10000 GROUP BY a.sql_id, o.object_name, a.event ORDER BY cnt DESC;
查到 SQL 后，怎么判断是 I/O 路径问题还是 SQL 本身问题？
同一 sql_id 在不同节点上 direct path read 平均等待差异超过 3 倍，基本可判定是 RAC 非对称 I/O。此时不要急着改 SQL：
- 先查该 SQL 涉及的数据文件路径：
SELECT file_name FROM dba_data_files WHERE file_id IN (SELECT file_id FROM dba_extents WHERE segment_name = 'XXX') - 再查这些文件所在磁盘组的 failgroup 分布：
SELECT failgroup, state, total_mb FROM gv$asm_disk WHERE group_number IN (SELECT group_number FROM v$asm_alias WHERE name = 'XXX') - 最后比对各节点的
iostat -x /dev/mapper/mpatha 1 5输出：如果某节点await持续 >25ms 而其他节点
注意：direct path read 不经过 buffer cache，所以调大 db_cache_size 或加索引对此类等待无效；真正有效的动作是迁移数据文件、调整 ASM failgroup、或停掉争用的备份任务。
容易被忽略的两个硬伤
一是 v$sort_usage.SQL_ID 完全不可信，它来自 v$session.prev_sql_id，只要会话执行了新语句，旧临时段就彻底断连；二是 direct path read 在 ASH 中不记录 p1text/p2text（即 file#/block#），所以无法像 db file sequential read 那样下钻到具体块级热点——你只能定位到对象或 SQL，没法精确定位到哪几 MB 文件区域。这意味着优化必须从逻辑层（SQL 执行计划、并行度、临时表空间配置）和物理层（LUN 划分、failgroup 均衡、multipath 配置）双线推进，单靠数据库内部分析必然漏掉一半真相。
