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来用——它只在单次查询的生命周期内有效，不应该出现在物化视图这种跨事务、跨时间的数据快照里。
