direct path read等待突增通常源于并行查询自动启用、PGA不足导致temp读或_serial_direct_read被误设为ALWAYS；需查v$session_wait、v$px_session、v$tempseg_usage及physical reads direct指标定位根因。
direct path read 等待突然变多，先看是不是并行查询在“偷偷干活”
oracle 12c 默认对大表全表扫描启用自动并行（尤其当 _parallel_statement_policy = auto 且对象有并行度设置时），而并行从属进程（px slave）几乎必然走 direct path read —— 它们不进 buffer cache，直接把数据块读进各自 pga。你看到的“剧增”，很可能是某条 sql 被自动并行化后，拉起十几个 slave 进程，每个都在等磁盘读。
验证方法：
- 查 v$session_wait 中 event = 'direct path read' 的会话，看 sid 是否属于 PX 类型（program 含 P00、P01 等）；
- 查 v$px_session，确认这些会话是否关联到同一个 qcsid（Query Coordinator）；
- 在 AWR 报告中看 “SQL ordered by Parallel Executions”，找执行次数高、并行度大的语句。
临时缓解：
- 对问题 SQL 加 /*+ NO_PARALLEL */ 提示；
- 或全局禁用自动并行：设 _parallel_statement_policy = MANUAL（需重启或 ALTER SYSTEM，注意影响范围）；
- 切勿直接调高 parallel_max_servers 来“解决等待”，这只会让问题更严重。
PGA 不够用时，direct path read temp 会冒出来顶替内存排序
当 SQL 执行 ORDER BY、GROUP BY 或 HASH JOIN，而 PGA_AGGREGATE_TARGET 不足以容纳中间结果时，Oracle 会把溢出部分写入 TEMP 表空间（触发 direct path write temp），后续再从 TEMP 读回来（触发 direct path read temp）。这类等待常伴随 TEMP 表空间使用率飙升、physical reads direct 统计值暴涨。
关键判断点：
- 查 v$tempseg_usage，确认哪些会话正在用 TEMP，segtype 是 SORT 还是 HASH；
- 查 v$sesstat 中 physical reads direct temp 值高的会话，再关联到其 sql_id；
- 检查该 SQL 的执行计划，看是否有 TEMP TABLE TRANSFORMATION、SPILL TO TEMP 或大量 SORT 操作。
调整建议：
- 若临时性负载升高，可短期增大 PGA_AGGREGATE_TARGET（比如 +2G），但必须同步监控 v$pgastat 的 cache hit percentage 和 bytes processed，避免盲目加码；
- 不要只调 sort_area_size（12c 已废弃手动模式），它只在 workarea_size_policy = MANUAL 下生效，而默认是 AUTO；
- 如果发现某条 SQL 总是 spill，优先考虑改写（如减少 SELECT *、加过滤条件提前截断数据量）。
_serial_direct_read 参数被误设为 ALWAYS，小表也强制走磁盘读
12c 中 _serial_direct_read 默认是 AUTO，Oracle 根据表大小（对比 _small_table_threshold）和缓存热度决定是否走直接路径。但若 DBA 手动设为 ALWAYS，哪怕只有几十行的配置表，串行查询也会绕过 Buffer Cache，每次都是物理读 —— 表面看是 direct path read 等待增多，实际是大量本该命中缓存的逻辑读被转化成了低效物理读。
快速检查：
- 运行：SELECT ksppinm, ksppstvl FROM x$ksppcv WHERE ksppinm = '_serial_direct_read';
- 若返回 ALWAYS，且业务以 OLTP 为主、小表访问频繁，这就是根因。
修复动作：
- 改回 AUTO：ALTER SYSTEM SET "_serial_direct_read" = AUTO SCOPE=BOTH;
- 注意：该参数修改后，已打开的游标不会立即生效，需刷新共享池或等游标老化；
- 避免设为 NEVER，否则可能抑制真正需要直接路径的大表扫描（如报表类 SQL），得不偿失。
别只盯着等待事件本身，physical reads direct 才是真实工作量指标
v$session_event.time_waited 对 direct path read 的统计在并行场景下严重失真：PX slave 的等待时间不计入父会话，且异步 I/O 可能导致重复计数或漏计。靠这个值判断“瓶颈”极易误判。
更可靠的做法：
- 查 v$sesstat 中 physical reads direct 和 physical reads direct temp 的累计值，按会话或 SQL 分组；
- 结合 v$sql 的 disk_reads 和 buffer_gets，算出物理读占比（disk_reads / (disk_reads + buffer_gets)），>30% 就值得深挖；
- 对比 AWR 中 “Physical Reads Per Sec” 趋势图，确认是否真有 I/O 量激增，而非仅等待时间统计偏差。
最容易被忽略的一点：
- 即使所有参数都调得合理，如果底层存储响应慢（如单块读平均耗时 >10ms），direct path read 等待时间仍会拉长——此时优化方向应转向 I/O 子系统（检查 ASM diskgroup 平衡性、存储队列深度、是否误配了 RAID5），而不是继续调 Oracle 内存参数。
