Oracle 12c分区表主键冲突导致物化视图刷新错误的解决方法

ORA-12032这个错误，看上去像是主键冲突的报错，但实际根因往往有点绕——它不是数据打架，而是物化视图定义里，日志类型和查询引用之间“对不上号”。

具体来说，当一个UNION ALL物化视图的SELECT中间出现了某个表的rowid，比如b.rowid zrrrid，Oracle就认定这个视图要求所有参与表都提供ROWID字段。可如果给t_dj_zrr建的却是WITH PRIMARY KEY日志，那日志里压根没有ROWID列。刷新时一校验，日志里找不到这个字段，ORA-12032就抛出来了。错误信息里明确提到T_DJ_ZRR，正好印证了问题出在该表的日志与引用不匹配，而不是主键重复或数据冲突。

关键判断点在于：

• SELECT列表里只要出现一个rowid（哪怕只在某一个分支），整个物化视图的日志就必须统一升级为WITH ROWID模式，且所有表日志都得包含ROWID字段。
• 反过来，WITH PRIMARY KEY日志不生成ROWID，也不允许你在SELECT中引用基表的ROWID伪列。
• 错误信息指向哪个表，就说明哪个表的日志类型和查询定义有冲突，跟数据本身没关系。

UNION ALL 物化视图必须统一日志策略

多表UNION ALL场景下，Oracle不支持混合日志类型。你不能一部分表用PRIMARY KEY，另一部分用ROWID；也不能有的分支引用rowid，有的不引用。

可行方案只有两个，二选一：

• 全部改用WITH ROWID日志：重建所有三张表的日志，加上ROWID，删掉PRIMARY KEY。注意，需要确认基表没有被ALTER TABLE ... MOVE过，否则ROWID会失效。
• 全部改用WITH PRIMARY KEY日志：删掉SELECT中所有rowid引用（如a.rowid jgrid、c.rowid fbrid、b.rowid zrrrid），只保留业务主键字段。同时，必须确保每张表的主键列名和数据类型完全一致，比如都是nsrnbm，类型VARCHAR2(20)。

注意，WITH PRIMARY KEY模式要求所有表的主键列名相同且类型兼容，而且物化视图定义里不能出现ROWID或OBJECT_ID这类伪列。

主键列名不一致或隐式转换会悄悄导致刷新失败

即便日志类型统一了，如果各表主键列名不一样（比如一张叫nsrnbm，另一张叫tax_id），或者类型不对齐（VARCHAR2(15) vs VARCHAR2(20)），Oracle在FAST刷新时无法对齐变更行，就会静默退化为COMPLETE刷新。后续很可能报ORA-12008或锁表超时。

检查步骤：

• 查日志字段：SELECT column_name FROM user_mview_log_columns WHERE log_table = 'MLOG$_T_DJ_JGNSR'，确认主键列确实在日志中
• 比对主键定义：SELECT column_name, data_type, data_length FROM all_constraints c JOIN all_cons_columns cc USING (owner, constraint_name, table_name) WHERE c.constraint_type = 'P' AND c.table_name IN ('T_DJ_JGNSR', 'T_DJ_ZRR')
• 警惕隐式转换：如果主键是数字型但值带前导零（如'00123'），而另一张表存为NUMBER，比较时会失败。统一用字符型更稳妥。

为什么物化视图里不能留着 rowid 别名当业务字段用

有些人习惯保留a.rowid jgrid作为“来源标识”，但这个习惯在物化视图里非常危险。ROWID是物理地址，随MOVE、SHRINK、分区SPLIT等操作就会失效。由于物化视图跨越多个事务，一旦ROWID变成无效地址，后续DML变更就无法正确定位行，轻则数据错乱，重则报ORA-12008。

替代做法：

• 用业务主键代替：a.nsrnbm jgrid，既稳定又可索引
• 加来源标记字段：'jgnsr' AS source_type，语义比rowid清晰得多
• 如果真需要唯一行标识，可以在基表加一个surrogate_id列，通过序列+触发器自动生成，并纳入日志和MV的SELECT列表

真正麻烦的从来不是错误代码本身，而是把rowid当成通用ID来用——它只在单次查询的生命周期内有效，不应该出现在物化视图这种跨事务、跨时间的数据快照里。