direct path write等待飙升主因是SQL绕过Buffer Cache直写磁盘，常见于CTAS、INSERT /+ APPEND /、并行DML或LOB写入；需通过v$sesstat查physical writes direct定位高写入会话，结合P1判断写入位置（数据文件/TEMP/LOB），再针对性禁用、调优或改写SQL。
direct path write 等待飙升，基本就是某条 sql 正在绕过 buffer cache 往磁盘猛写，常见于 ctas、insert /*+ append */、并行 dml 或大量 lob 写入 —— 先定位它，再看是不是该禁、该调、还是该改。
查哪个会话在疯狂 direct path write
别只盯着 v$session_wait.event = 'direct path write'，这个等待本身不反映真实 I/O 次数，且异步 IO 下时间统计失真。真正靠谱的是看写入量：
- 用
v$sesstat查物理直写次数：SELECT s.sid, s.sql_id, t.name, ss.value FROM v$sesstat ss, v$statname t, v$session s WHERE ss.statistic# = t.statistic# AND ss.sid = s.sid AND t.name = 'physical writes direct' AND ss.value > 10000 ORDER BY ss.value DESC;
- 结合
v$session_wait的参数 P1（file#）判断写入位置：- 若 P1 值落在
v$datafile.file#范围内 → 是数据文件直写（CTAS / APPEND） - 若 P1 值落在
v$tempfile.file# + (select value from v$parameter where name='db_files')范围内 → 是临时表空间写（排序/哈希溢出） - 若 P1 对应的是 LOB 表空间的文件 → 看是否在插入/更新
BLOB或CLOB字段（如TICKETIMAGE这类大字段）
- 若 P1 值落在
确认是不是 CTAS 或 APPEND 插入在捣鬼
CTAS 和带 /*+ APPEND */ 的 INSERT 是 direct path write 最典型的触发点，它们跳过 Buffer Cache，直接把 PGA 里的数据块刷进数据文件。但前提是：
- 目标表没被
NOLOGGING禁用（否则可能退化为常规路径） - 表不是索引组织表（IOT）、聚簇表或有启用加密的列
- 没有开启
FORCE LOGGING（会强制走 redo，但不阻止 direct path write） - 执行用户有
UNLIMITED TABLESPACE或对应表空间配额（否则可能卡在空间分配上，表现为长时间等待）
快速验证：抓问题时段的 AWR 或 ASH 报告，看 “SQL ordered by Physical Writes Direct” 部分，找 sql_text 含 CREATE TABLE AS SELECT 或 INSERT /*+ APPEND */ 的语句；再查其执行计划，确认 LOAD AS SELECT 或 LOAD TABLE CONVENTIONAL 是否出现 —— 前者才是 direct path。
LOB 写入或临时段写入导致的 direct path write 怎么区分
同样是 direct path write，写 LOB 段和写 TEMP 段的优化思路完全不同：
-
写 LOB 段（如 BLOB）：常见于应用层批量上传图片、附件。这类操作默认走 direct path write（尤其
SECUREFILELOB），IO 压力直接打在存储上。可临时关闭特性：ALTER SYSTEM SET "_direct_path_insert_features"=1;
（注意：这是隐含参数，仅限紧急缓解，升级后行为可能变化） -
写 TEMP 表空间：说明 SQL 在做大规模排序（
ORDER BY）、哈希连接（HASH JOIN）或聚合（GROUP BY）时 PGA 不够，溢出到磁盘。此时v$tempseg_usage中segtype = 'SORT'或'HASH'的记录会暴增。不要盲目加PGA_AGGREGATE_TARGET，先看执行计划里有没有SPILL TO TEMP或TEMP TABLE TRANSFORMATION，优先考虑加过滤条件、建合适索引、或改写 SQL 减少中间结果集。
别碰的“解法”和容易忽略的细节
很多人一看到等待就本能想调参数，但以下操作风险极高或根本无效：
- 不要设
_serial_direct_read = ALWAYS—— 这是给读用的，对 write 无影响，反而会让小表全扫也走磁盘读，雪上加霜 - 不要调高
parallel_max_servers来“加速写入” —— 并行 DML 会放大 direct path write 并发度，IO 队列更长，等待更久 - 别只看
DISK_ASYNCH_IO = TRUE就以为万事大吉 —— 它只是让等待计时不准确，不代表 I/O 真的快了；底层存储延迟（比如慢盘、RAID5 写惩罚、SAN 队列深度不足）才是根因 - 最常被忽略的一点：
direct path write本身不是瓶颈，它是现象。真正要盯的是“为什么这条 SQL 必须走 direct path？”—— 是数据量太大？设计不合理？还是临时开了 NOLOGGING 却没配好归档？
