根本原因是Oracle对分区表执行Direct Path加载时默认逐分区单独写入，引发大量小IO和元数据刷新；需确保分区裁剪生效、目标分区NOLOGGING、并行与APPEND正确配置。
Direct Path加载为什么在分区表上反而变慢
根本原因不是direct path本身有问题，而是oracle默认对每个分区单独做一次直接路径写入，触发大量小io和元数据刷新。尤其当分区数多（比如按天分1000个区）、单次导入数据量又不大时，开销全花在“启动/关闭直接路径会话”和“更新分区级高水位线”上了。
- 现象：
INSERT /*+ APPEND */跑得比普通INSERT还慢，v$session_longops里看到大量Load as Select等待，但db file scattered read并不高 - 关键点：分区表的
APPEND本质是“逐分区直写”，不是“整表直写”——哪怕你只插一个分区的数据，Oracle仍要扫描所有分区的元数据来确认目标位置 - 验证方式：查
dba_tab_partitions确认分区数；用10046 trace看是否出现重复的kcbzgb（缓冲区获取）和kdsts（直接路径初始化）调用
禁用索引后LOAD DATA仍卡在INDEX MAINTENANCE阶段
禁用索引（ALTER INDEX ... UNUSABLE）只是让优化器跳过它，但SQL*Loader或INSERT /*+ APPEND */在提交时仍会尝试重建全局索引的分区键映射，尤其是本地索引（LOCAL）未显式指定UPDATE INDEXES时，Oracle会默默做一次全索引扫描校验。
- 典型错误：
ORA-01502: index 'XXX' or partition of such index is in unusable state—— 实际不是报错，而是卡在后台恢复逻辑里 - 正确做法：对本地索引，必须加
UPDATE INDEXES (idx_name (partition_name))；对全局索引，要么提前DROP，要么确保NOLOGGING且表空间支持快速恢复 - 注意：
DISABLE VALIDATE不等于UNUSABLE，前者锁结构后者才真正绕过维护，别混用
分区表批量导入的三个实操底线配置
不调这三项，Direct Path在分区表上大概率白忙活：
-
ALTER SESSION SET "_serial_direct_read" = ALWAYS—— 强制走直接读，避免因统计信息不准导致走buffer cache路径 -
ALTER TABLE t1 PARALLEL 8 NOLOGGING—— 并行度设为分区数的1/4～1/2（非CPU核数），且必须NOLOGGING，否则日志生成压垮LGWR - 导入前执行：
ALTER TABLE t1 MODIFY PARTITION p20240101 NOLOGGING—— 只对目标分区关日志，别动整个表，否则影响其他业务查询
示例：向t_sales的p20240101分区导入，命令里必须带PARALLEL(DEGREE 4)和APPEND，且loader控制文件里明确写INTO TABLE t_sales PARTITION (p20240101)。
为什么分区裁剪失效会让Direct Path退化成常规插入
如果WHERE条件或分区键值没被优化器识别为静态可裁剪（比如用了绑定变量、函数包装、或者分区键类型不匹配），Oracle就无法确定数据只进某几个分区，于是退回到逐行检查+常规DML路径，APPEND提示彻底失效。
- 常见坑：
TO_DATE(:b1, 'yyyymmdd')传字符串给DATE分区键 → 分区裁剪失败；part_key = TO_CHAR(SYSDATE, 'yyyymmdd')→ 类型隐式转换阻断裁剪 - 验证方法：加
/*+ GATHER_PLAN_STATISTICS */跑explain plan，看Partition Start/Stop列是不是显示具体分区名，而不是KEY或ROW LOCATION - 救急方案：用
DBMS_SQLTUNE.LOAD_SQLSET抓真实执行计划，别信预估；分区键务必用字面量或确定性表达式
分区表导入性能问题，核心不在“要不要用Direct Path”，而在于“Oracle到底知不知道你要往哪几个分区写”。所有优化都得围着这个判断转，其它都是枝节。
