ORA-12032根因是UNION ALL物化视图中混用ROWID与PRIMARY KEY机制：T_DJ_ZRR建了PRIMARY KEY日志，但SELECT中引用b.rowid，而该日志不含ROWID字段；必须统一所有表为ROWID日志（含ROWID）或全部改用PRIMARY KEY日志（删所有rowid引用并确保主键列名类型一致）。
ORA-12032 出现在 UNION ALL + 主键刷新场景时怎么定位根因
这个错误不是主键本身冲突，而是物化视图定义里混用了 rowid 和 primary key 两种刷新机制——oracle 在 union all 查询中要求所有分支表的日志类型必须一致，但你给 t_dj_zrr 建的是 with primary key 日志，而查询里又引用了它的 rowid（b.rowid zrrrid），触发强制校验 rowid 列存在，结果日志里没它，就报 ora-12032。
关键判断点：
-
SELECT列表里只要出现任意一个rowid（哪怕只在某一分支），整个物化视图就**必须**用WITH ROWID日志，且所有参与表的日志都得含ROWID -
WITH PRIMARY KEY日志不生成ROWID字段，也不允许 SELECT 中引用基表ROWID - 错误信息里明确指向
T_DJ_ZRR，说明问题出在该表日志与查询引用不匹配，不是主键重复或数据冲突
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），只保留业务主键字段；确保每张表的主键列名和类型完全一致（比如都是nsrnbmVARCHAR2(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 等操作失效，物化视图一旦刷新就会丢失关联性，后续 DML 变更无法正确定位行，导致数据错乱或 ORA-12008。
替代做法：
- 用业务主键代替：
a.nsrnbm jgrid，既稳定又可索引 - 加来源标记字段：
'jgnsr' AS source_type，比rowid更语义清晰 - 若真需唯一行标识，建序列+触发器在基表加
surrogate_id列，并纳入日志和 MV SELECT 列表
真正麻烦的从来不是错误代码本身，而是把 rowid 当成通用 ID 用——它只在单次查询生命周期内有效，不该出现在物化视图这种跨事务、跨时间的数据快照里。
