怎样在Oracle中利用并行DML大幅提升大批量SQL UPDATE的效率？

Oracle的UPDATE语句默认不走并行，需先执行ALTER SESSION ENABLE PARALLEL DML，再配合严格语法的PARALLEL Hint（如UPDATE /+ PARALLEL(t 4) / t SET...），且DOP设置需结合硬件与等待事件谨慎调优。

Oracle的UPDATE语句默认完全不走并行，哪怕你写了/*+ PARALLEL */提示也无效——这是硬性限制，不是配置没调好。

ALTER SESSION ENABLE PARALLEL DML 必须显式执行

并行DML（PDML）在Oracle中是会话级显式开关，默认关闭。不执行这句，所有UPDATE都强制串行。

• ALTER SESSION ENABLE PARALLEL DML必须在UPDATE语句之前单独执行，不能和SQL写在同一PL/SQL块里却放在UPDATE后面
• 该命令只对当前会话生效，连接池（如Druid、UCP）每次取连接后都得重执行一次，建议封装进连接初始化逻辑
• 执行后可通过SELECT * FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV', 'SID')查PDML_STATUS字段确认是否为ENABLED

PARALLEL Hint 写法必须严格匹配目标表别名

Hint被忽略的最常见原因是语法错位或对象引用错误，Oracle不会报错，只会静默降级。

• Hint必须紧贴UPDATE关键字后，例如：UPDATE /*+ PARALLEL(t 4) */ t SET ...，不能写成UPDATE t /*+ PARALLEL(t 4) */ SET ...
• 如果UPDATE子句中用了别名（如UPDATE my_table t SET ...），Hint里必须用这个别名t，不能用原表名my_table
• 若没定义别名，又想用PARALLEL，必须先加别名：UPDATE my_table t /*+ PARALLEL(t 4) */ SET ...
• 带子查询（如WHERE EXISTS）时，PARALLEL只作用于主表t，子查询仍串行，别指望整个语句并行化

并行度（DOP）设置不当反而引发锁争用

设PARALLEL(t 16)不等于真跑16个PX进程，高DOP在UPDATE场景下极易触发enq: TX - row lock contention或ORA-12838错误。

• 实际DOP受CPU_COUNT、PARALLEL_THREADS_PER_CPU、PARALLEL_MAX_SERVERS三者共同限制，可用SELECT * FROM V$OSSTAT WHERE STAT_NAME IN ('NUM_CPUS', 'PHYSICAL_MEMORY_BYTES')查硬件上限
• UPDATE是写操作，DOP过高会导致热点块竞争，尤其当更新主键/索引键连续值时，buffer busy waits飙升
• 建议起始DOP设为min(4, CPU_COUNT / 2)，再根据AWR报告中gc buffer busy和enq: TX等待事件调整
• 分区表可配合PARTITION子句进一步限定范围，避免跨分区扫描

并行DML + BULK COLLECT + FORALL 是更稳的组合方案

纯PARALLEL UPDATE适合全表或大范围条件更新；但若需根据关联查询结果更新（比如“用表B更新表A”），FORALL批量+并行DML混合用更可控。

• 先用BULK COLLECT INTO把驱动数据（如ID+新值）加载到PL/SQL集合，避免游标逐行开销
• 再用FORALL i IN 1..arr.COUNT UPDATE ... WHERE id = arr(i).id，此时每个UPDATE本身仍是单条，但批量提交减少上下文切换
• 若该FORALL块所在会话已启用PARALLEL DML，且UPDATE语句含合法PUBLIC提示，则每条UPDATE可能并行执行——但注意：Oracle对FORALL内单条语句的并行支持有限，实测中更推荐将FORALL用于非并行场景，而把PARALLEL留给独立的大范围UPDATE
• 真正要压榨性能，优先考虑CREATE TABLE AS SELECT或INSERT /*+ APPEND */重建表，再RENAME切换，比原地UPDATE快一个数量级

并行DML不是开关一开就提速，它把资源争用从I/O搬到了锁和内存结构上。最容易被忽略的是：UPDATE的并行收益高度依赖数据分布——如果WHERE条件命中大量相邻数据块，DOP再高也卡在buffer cache争用上。