Direct Path Read 变慢主因是并行资源争用、I/O路径瓶颈或内存配置不当；需结合AWR中direct path read等待时间、Parallel Operations Queued值、v$iostat_function及oratop定位根因。
Direct Path Read 为什么突然变慢？先看 AWR 里这三项指标
direct path read 变慢通常不是单点问题，而是并行查询在 i/o 或内存资源上被挤压的信号。直接查 awr 报告里的 db time、direct path read 等待事件占比，以及 parallel operations not queued 和 parallel operations queued 这两个统计项——如果后者显著上升，说明并行服务器进程排队了，哪怕 sql 本身没改，也可能因并发负载升高触发资源争用。
实操建议：
- 用
awr_report_text.sql或 OEM 导出最近 2 小时的 AWR 报告，重点定位 Top 5 Timed Foreground Events 中direct path read的平均等待时间（ms）是否突增（比如从 5ms 升到 80ms） - 检查 Instance Activity Stats 表中
parallel operations queued值：若非零且持续增长，说明PARALLEL_SERVERS_TARGET设置过低或系统 CPU/IO 已饱和 - 确认该 SQL 是否真走 direct path：查
v$sql_plan，operation为TABLE ACCESS STORAGE FULL或LOAD AS SELECT，且options含STORAGE或DIRECT LOAD
并行度（DOP）设置不当是 Direct Path Read 卡顿最常见原因
Oracle 不会自动“降级”DOP，哪怕物理 I/O 能力已满，它仍按提示或对象级别设定启动并行进程，结果大量进程争抢磁盘队列，单个 direct path read 等待飙升。
实操建议：
- 检查 SQL 中是否硬编码
/*+ PARALLEL(t, 32) */—— 若表实际只有 4 个数据文件，DOP=32 极易导致 I/O skew；应改用/*+ PARALLEL(t, 4) */或依赖ALTER TABLE t PARALLEL 4的默认值 - 确认
PARALLEL_DEGREE_POLICY是AUTO还是MANUAL：AUTO下 Oracle 会参考PARALLEL_SERVERS_TARGET动态限制并发数，但需确保该参数 ≥ 实际活跃并行任务所需进程数 × 2（留缓冲） - 避免混合使用
PARALLELhint 和NO_PARALLELhint：后者不覆盖前者，可能引发计划不稳定；统一用OPTIMIZER_IGNORE_HINTS+ SQL Profile 锁定 DOP
临时表空间和 PGA 配置直接影响 Direct Path Read 效率
Direct Path Read 常伴随大排序、哈希连接或全局临时表（GTT）写入，这些操作若无法在 PGA 完成，就会 spill 到临时表空间，触发额外的 direct path write temp + direct path read temp 循环，I/O 放大数倍。
实操建议：
- 查
v$pgastat的bytes processed和extra bytes read/written比值：若后者 > 前者 20%，说明严重溢出，需调大PGA_AGGREGATE_TARGET（注意：不是简单翻倍，要结合v$pga_target_advice建议） - 临时表空间不能放在高延迟设备上：比如 ASM diskgroup 使用
NORMAL REDUNDANCY但底层是 SATA 盘，direct path read temp延迟必然高；应迁至HIGH REDUNDANCY+ SSD diskgroup - 对 GTT 大量使用的场景，启用
ON COMMIT PRESERVE ROWS并配合/*+ APPEND */，可减少 redo 和 buffer cache 争用，间接降低 direct path read 的锁等待
AWR 报告里看不到真实 I/O 瓶颈？补查 v$iostat_function 和 oratop
AWR 的 direct path read 等待只反映数据库层感知到的延迟，但底层可能是存储队列深度过高、HBA 卡中断不均、甚至 OS 文件系统缓存污染。这些不会直接出现在 AWR 的 SQL 或事件分析里。
实操建议：
- 运行
SELECT function_name, small_read_reqs, small_write_reqs FROM v$iostat_function WHERE function_name LIKE '%Direct%';—— 若small_read_reqs极高但吞吐低，说明 I/O 请求碎片化，需检查是否用了小块读（如DB_FILE_MULTIBLOCK_READ_COUNT设为 8，而存储条带大小是 1MB） - 在数据库服务器上实时跑
oratop -d（需安装），观察IOw（I/O wait）和IOa（I/O active）列：若IOw> 80% 且IOa接近 100%，基本可判定是存储响应慢，而非 Oracle 配置问题 - 确认
filesystemio_options参数为SETALL（Linux 下）或ASYNCH（AIX），否则 direct path 会退化为同步 I/O，失去绕过 buffer cache 的优势
真正卡住 Direct Path Read 的，往往不是 SQL 写法，而是并行资源、I/O 路径和内存配置三者的隐性冲突。AWR 能告诉你“哪里慢”，但得靠 v$iostat_function 和 oratop 才能确认“为什么慢”。漏掉任一环节，调优就只是在换参数碰运气。
