ALTER TABLE … PARALLEL 未生效，是因为它仅设置对象级默认并行度，实际并行需语句显式触发、会话启用PDML、且操作类型支持；单分区READ ONLY时DEGREE被忽略，必须用Hint控制。
分区表上 ALTER TABLE … PARALLEL 为什么没效果
直接对分区表执行 ALTER TABLE sales_part PARALLEL 4 不会自动让后续 DML 或查询变并行——它只设置对象级默认并行度（DEGREE），但实际是否启用，取决于语句是否显式触发并行、会话是否启用 PDML、以及目标操作类型。
常见错误是以为设了表级并行度，UPDATE 或 INSERT /*+ APPEND */ 就能自动并行。实际上：
-
UPDATE/DELETE必须先执行ALTER SESSION ENABLE PARALLEL DML，否则所有 hint 都被忽略 -
INSERT /*+ APPEND */默认不走并行，需额外加/*+ parallel(t, 4) */且确保目标表无 ENABLED 触发器 - 分区表的单个分区若为
READ ONLY，其DEGREE值会被跳过，必须靠 hint 显式控制
跨分区 DDL 维护（如 TRUNCATE/DROP）如何真正并行
Oracle 12c+ 支持一次操作多个分区，但并行性不是自动开启的——ALTER TABLE t TRUNCATE PARTITIONS p202501,p202502 仍是串行执行，除非你用 DBMS_PARALLEL_EXECUTE 拆解任务，或改用 INSERT /*+ APPEND PARALLEL */ + EXCHANGE PARTITION 替代。
更实用的并行维护路径：
- 对大分区做
TRUNCATE PARTITION前，先ALTER TABLE t MODIFY PARTITION p202501 PARALLEL 8，再配合ALTER SESSION ENABLE PARALLEL DML执行DELETE /*+ parallel(t, 8) */ FROM t PARTITION (p202501) - 用
EXCHANGE PARTITION把旧分区和空表交换，再并行清空空表：INSERT /*+ append parallel(t, 4) */ INTO empty_t SELECT * FROM old_partition - 避免在高并发窗口执行
DROP PARTITION，它会持有TM锁，阻塞其他 DML；优先用TRUNCATE+UPDATE GLOBAL INDEXES
并行 DML 在分区表上的 DOP 设置陷阱
写错 DOP 容易让性能不升反降。Oracle 不按“分区数 × 单分区 DOP”分配进程，而是把匹配的所有分区视为一个数据集，统一调度最多 DOP 个并行服务进程（P000–P00n）。
典型误判点：
- 查 3 个分区却设
/*+ parallel(t, 16) */：多余进程闲置，还加剧enq: TX - row lock contention - 非分区表设 DOP > 8，收益断崖下降；分区表设 DOP 超过实际命中分区数，无意义
- 复合分区（Range+Hash）下，子分区数 ≠ 可并行单元数——优化器按主分区粒度调度，子分区只是物理存储细节
- 初始建议值：
min(4, CPU_COUNT / 2)，观察 AWR 中gc buffer busy和enq: TX等待事件上升就立刻回调
验证并行是否真生效的硬指标
别只看执行计划里有没有 PX 字样——那是 optimizer 计划，不是 runtime 行为。真实并行必须同时满足：
-
EXPLAIN PLAN输出含PX COORDINATOR、PX SEND、PX RECEIVE - 运行时查
v$px_session，有活跃的Pxxx进程且QCSID指向你的会话 - AWR 报告中
Parallel Operations部分显示非零的Parallel Queries/Parallel DMLs数量 - 对
UPDATE类操作，还需确认v$transaction中USED_UBLK增长速率明显快于串行基准
最容易被忽略的是：分区大小低于 10MB 时，Oracle 19c 默认不启动并行扫描，哪怕 hint 写得再全——查 DBA_SEGMENTS.BYTES 确认分区物理大小，比看行数更可靠。
