Direct Path Write过高需立即定位SQL并干预，通过v$sesstat查physical writes direct定位高写入SQL，再结合v$session_wait.P1判断写入目标（数据文件/临时表空间/LOB段），针对性优化。
Direct Path Write 过高不是“等它自己降下来”的问题，而是某条 SQL 正在绕过 Buffer Cache 猛写磁盘——必须立刻定位、判断、干预。
怎么快速定位是哪条 SQL 在狂写
别只盯着 v$session_wait.event = 'direct path write'，这个等待时间在异步 I/O 下严重失真，且不反映真实写入量。真正靠谱的是查物理直写次数：
- 运行：
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; - 拿到高值
sql_id后，用SELECT sql_text FROM v$sql WHERE sql_id = '<xxx>';看语句内容 - 重点盯：含
CREATE TABLE AS SELECT、INSERT /*+ APPEND */、INSERT /*+ APPEND_VALUES */的语句，或大量BLOB/CLOB字段更新
怎么判断写的是数据文件、临时表空间还是 LOB 段
光知道 SQL 不够，得看它往哪儿写——这决定你下一步是调参数、扩空间，还是改逻辑：
- 查该会话的
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 表空间的文件号 → 检查是否在插入/更新大对象字段（如TICKETIMAGE）
不同写入目标的应对策略差异很大
同一类等待，原因不同，解法完全相反：
- 写数据文件（CTAS / APPEND）：确认是否真需要直接路径——如果表后续要频繁查询，
HWM会被推高，全表扫描变慢；可考虑去掉/*+ APPEND */改为常规插入，或事后执行ALTER TABLE ... SHRINK SPACE（需先ENABLE ROW MOVEMENT） - 写临时表空间（
direct path write temp）：先查dba_temp_files是否已满或未启用自动扩展；临时文件大小不够时，扩空间比调 PGA 更有效——ALTER DATABASE TEMPFILE '<path>' AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED; - 写 LOB 段：检查是否用了
NOLOGGING但没配STORAGE (BUFFER_POOL KEEP)，或 LOB 列未设DISABLE STORAGE IN ROW导致小 LOB 也走磁盘；大字段批量写入建议分批次 +DBMS_LOB.WRITEAPPEND替代单次大 INSERT
容易被忽略的隐性条件
即使写了 /*+ APPEND */，也不一定真走 Direct Path——这些条件不满足就会退化为常规路径，但你可能还在等它“快”，结果卡在锁或空间分配上：
- 目标表启用了
FORCE LOGGING→ 仍走 direct path write，但 redo 增多，I/O 压力翻倍 - 表有启用透明数据加密（TDE）的列 → 直接路径被禁用， silently 降级为 conventional insert
- 用户没有对应表空间的配额，或
UNLIMITED TABLESPACE权限不足 → 会卡在空间分配环节，表现为长时间direct path write等待，实则是空间申请阻塞 - 并行 DML 未显式
ALTER SESSION ENABLE PARALLEL DML→ 即使写了PARALLELhint，也不会触发 direct path
真正麻烦的从来不是“怎么让它快”，而是“它为什么没按预期走 direct path”或者“它快了但把 HWM 推到天上去，后续查询全崩”。定位时务必交叉验证 sql_id、P1、执行计划里的 LOAD AS SELECT 和表属性，漏掉任一环都可能白调半天。
