Oracle 12c中的direct path write等待怎么解决_排查CTAS或插入操作性能

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.valueFROM v$sesstat ss, v$statname t, v$session sWHERE ss.statistic# = t.statistic#  AND ss.sid = s.sid  AND t.name = 'physical writes direct'  AND ss.value > 10000ORDER 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 这类大字段）

确认是不是 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（尤其 SECUREFILE LOB），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 却没配好归档？