物化视图刷新时出现 ORA-12801 / ORA-00600，是不是数据倾斜导致的？
先说一个核心判断：数据倾斜很可能是导致物化视图刷新时出现 ORA-12801/ORA-00600 的原因，尤其在基表 GROUP BY 字段分布不均且启用并行时，易引发并行进程负载失衡、超时或内存溢出。
物化视图刷新时出现 ORA-12801 / ORA-00600，是不是数据倾斜导致的？
可能性非常高。当物化视图的基表按照 GROUP BY 字段（比如 region_id）存在严重的数据分布不均时——例如，仅仅1%的分区却容纳了70%的数据——问题就来了。如果此时刷新操作启用了并行（PARALLEL），Oracle的并行服务器进程会按照数据块或键值范围进行静态的工作划分。这直接导致某些从属（Sla ve）进程的负载远远超过其他进程，从而触发超时、内存溢出或内部错误。当然，这不是百分之百会报错，但如果看到 ORA-12801: error signaled in parallel query server 后面跟着 ORA-00600，或者刷新操作长时间卡在 px server wait 这类等待事件上，那就是相当典型的信号了。
如何确认物化视图刷新是否存在数据倾斜？
别只盯着执行计划看——那只是“纸上谈兵”。要确认问题，必须查看实际运行时各个并行进程到底处理了多少数据。这里有几个实用的方法：
- 开启SQL跟踪：在刷新前执行
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';。然后执行刷新操作（比如调用DBMS_MVIEW.REFRESH），完成后用tkprof工具解析生成的trace文件。重点关注PX Server行的rows列，如果不同进程处理的行数差异超过5倍，就属于明显的倾斜。 - 查询动态性能视图：更轻量级的方法是，在刷新过程中查询
V$PQ_TQSTAT视图（需要SELECT_CATALOG_ROLE权限）。执行以下查询：SELECT dfo_number, tq_id, server_type, num_rows, elapsed_time FROM V$PQ_TQSTAT WHERE dfo_number = (SELECT MAX(dfo_number) FROM V$PQ_TQSTAT) ORDER BY tq_id, server_type;
观察同一个tq_id下，不同server_type对应的num_rows是否相差悬殊。这能直观地看到工作负载是否均衡。
调整分布策略：用 HASH 分区替代 RANGE/ LIST，但必须配合刷新方式
物化视图本身并不支持直接指定分区方式，但我们可以通过“基表预分区 + 刷新Hint”的组合拳来间接控制数据分布：
- 如果基表已经按照倾斜字段（例如
user_id）做了HASH分区（建议至少16个分区），那么在刷新时可以通过Hint强制走分区裁剪：/*+ USE_HASH(mv) PARALLEL(mv, 8) */。这种方式通常比Oracle默认的RANGE分发策略更均衡。 - 尽量避免在
CREATE MATERIALIZED VIEW语句中直接对倾斜字段进行GROUP BY（比如GROUP BY country_code）。一个更好的思路是，改用子查询先进行预聚合，然后再进行JOIN操作。这样可以把数据倾斜的“压力点”前置到一个可以单独调优的中间步骤。 DBMS_MVIEW.REFRESH过程中的method参数影响巨大。使用'C'（完全刷新）时，Oracle可能会重用并行计划；而使用'F'（快速刷新）时，如果物化视图日志缺失或者物化视图定义包含复杂表达式，操作可能会退化为串行执行，反而掩盖了并行下的倾斜问题。因此，稳妥的做法是先确保'C'模式能跑通，再进行调优。
并行度不是越高越好：设置 parallel_degree_limit 和绑定 hint
盲目地设置 ALTER SESSION SET PARALLEL_DEGREE_LIMIT = CPU 常常会加剧资源争抢，适得其反。真正有效的做法是：
- 先摸清家底：查询当前系统的可用并行槽位上限：
SELECT value FROM v$parameter WHERE name = 'parallel_servers_target';。然后将parallel_degree_limit设置为不超过该值的70%。 - 在刷新SQL中显式指定并行度，而不是依赖系统参数。例如使用
/*+ PARALLEL(4) */。这里建议从4开始，然后根据V$PQ_TQSTAT的监控结果，逐步尝试6→8→12，每次小幅增加，避免并行度跳变带来的不稳定。 - 在执行刷新前，先禁用自动并行DML：
ALTER SESSION DISABLE PARALLEL DML;。这可以防止在DML阶段意外启用并行，导致资源冲突和不可预知的行为。
话说回来，数据倾斜本质上是业务数据分布特性的体现，技术手段只能缓解，难以根除。有一个最容易被忽略的细节是：物化视图日志表（MLOG$）本身如果没有分区，那么其 SNAPTIME$$ 字段的频繁更新就会形成一个热点，导致快速刷新（fast refresh）卡在日志扫描阶段。到了这一步，再去调整并行度就毫无意义了，正确的做法是优先给物化视图日志表加上 HASH 分区。
