direct path read/write 是绕过 SGA 中 Buffer Cache、直接在磁盘与 PGA 间进行物理 I/O 的操作，用于避免大容量数据处理时缓存争用瓶颈，常见于全表扫描、并行查询、APPEND 插入等场景。
direct path read/write 是什么，为什么它不走 SGA
oracle 的 direct path read 和 direct path write 是绕过 buffer cache（即 sga 中的 database buffer cache）的物理 i/o 操作。它不把数据块加载进内存缓存，而是直接从磁盘读到 pga（比如排序区、哈希区），或从 pga 直接写回磁盘。常见于大表全表扫描、并行查询、insert /*+ append */、create table as select 等场景。
根本原因不是“想绕开”，而是设计上就为避免 Buffer Cache 成为瓶颈：当一次要处理几 GB 数据时，反复 pin/unpin 缓存块、维护 LRU 链、争用 cache buffers chains latch，反而比直读直写更慢。
所以你看到大量 direct path read 等待事件，并不等于“系统坏了”，而很可能是 Oracle 在按预期工作——尤其在并行执行计划里。
怎么确认某次 SQL 是否触发了 direct path I/O
关键看执行计划和实际运行时的等待事件，不是看语句写了什么 hint 就一定生效。
-
V$SESSION_EVENT或V$ACTIVE_SESSION_HISTORY中查event列是否含direct path read/direct path write - 执行计划中出现
LOAD AS SELECT、LOAD TABLE CONVENTIONAL（注意：后者是常规路径）、TABLE ACCESS FULL+ 并行服务器（如PX SEND QC）且伴随大量物理读，大概率走 direct path -
V$SQL的IO_CELL_OFFLOAD_ELIGIBLE_BYTES和IO_INTERCONNECT_BYTES不反映 direct path，但PHYSICAL_READ_BYTES显著高于DB_BLOCK_GETS+CONSISTENT_GETS总和，是个强信号 - 12c+ 可用
DBMS_SQLTUNE.REPORT_SQL_MONITOR查 I/O 类型分布，其中 “Direct Reads” 行明确标出字节数
并行执行下 direct path 的 I/O 分布和常见误判
并行 worker 进程（如 P000, P001）各自做 direct path I/O，但它们读的文件、block range 未必连续，也不保证顺序。这导致几个容易踩的坑：
- OS 层看到的是多个进程同时发起随机读（
pread64），不是单个大顺序读，监控工具可能误判为“I/O 散乱”或“热点文件” - ASM 磁盘组中，如果条带（AU）大小设得太小（如 1MB），而 direct path 每次读 128KB，默认对齐到 AU 边界，会造成跨 AU 读，放大物理 I/O 量
-
PARALLEL_DEGREE_POLICY = MANUAL时，即使加了/*+ PARALLEL(4) */，若对象未启用并行属性（ALTER TABLE t PARALLEL 4），仍可能退化为串行 direct path，但等待事件还是direct path read，让人误以为并行生效了 - 临时表空间不足时，
direct path write temp会暴涨，但日志里看不到明显报错，只表现为大量direct path write等待 + 排序性能断崖下跌
调整与优化的关键控制点
不能靠“关掉 direct path”来解决问题——它本就是高性能路径。真正该调的是触发条件和资源适配：
- 检查
_serial_direct_read隐含参数：默认auto，小结果集自动走 buffer cache；设为false强制禁用（仅调试用），但会严重拖慢大扫描 - 确保
DB_FILE_MULTIBLOCK_READ_COUNT合理（通常 128 或 256），它影响每次 direct path read 的最大 block 数，太小则 I/O 次数多，太大可能引发单次超时 - 并行度不要盲目设高：每个 worker 占用独立 PGA，
PGA_AGGREGATE_TARGET不足会导致频繁direct path write temp，甚至 OOM - 确认存储层是否支持异步 I/O：
disk_asynch_io = TRUE+ 文件系统/ASM 配置正确，否则 direct path 会退化为同步阻塞读，direct path read等待时间飙升
最常被忽略的一点：direct path 的 I/O 统计不计入 db file sequential/scattered read，所以 AWR 报告里物理读总量看着低，不代表磁盘真闲——得盯紧 physical read total bytes 和存储层的吞吐率。
