ORA-01031报错主因是权限未激活或未直授：需查SESSION_PRIVS确认CREATE TABLE等权限是否生效，若缺失则须直授（非角色）、启用角色（SET ROLE ALL）、配齐CREATE SESSION及表空间配额。
ORA-01031: 权限不足，但SELECT明明已授
因为 MERGE 不是只读操作，它隐式依赖三类权限：对目标表的 INSERT 和 UPDATE 权限，以及对源（USING 子句）对象的 SELECT 权限。即使你只写了 WHEN MATCHED THEN UPDATE，Oracle 仍会检查目标表的 INSERT 权限——这是语法强制要求，不是执行时才判断。
常见误判场景：
- DBA 只执行了
GRANT SELECT ON t2 TO user1，但忘了GRANT INSERT, UPDATE ON t1 TO user1 - 用角色（role）授予权限，而该角色在 PL/SQL 或存储过程上下文中不可用（角色权限在匿名块或触发器中默认不生效）
- 目标表是同义词（synonym），权限需授予底层基表，而非同义词名
为什么WITH子句或视图作源时仍报ORA-01031
当 USING 部分是视图、物化视图或带 WITH 的子查询时，Oracle 会递归验证视图定义中所有引用对象的 SELECT 权限。哪怕你有视图本身的 SELECT 权限，若视图底层查了 hr.employees，而你没被直接授予 hr.employees 的 SELECT，就会失败。
验证方法：
- 运行
SELECT owner, view_name, text FROM all_views WHERE view_name = 'YOUR_VIEW';，检查其text中涉及的表 - 确认你对每个被引用的基表都有显式
SELECT授权（不能仅靠角色） - 避免在
USING中嵌套多层视图，权限链越长越容易漏授权
ORA-30926 出现时，权限错误只是表象
ORA-30926: unable to get a stable set of rows in the source tables 看似权限问题，实则是 ON 条件匹配到目标表多行，违反了 MERGE 的原子性前提。此时即使权限全开，语句照样失败。
典型诱因：
-
ON (t1.name = t2.name)——name非唯一，t1中多个ID对应同一name -
USING子查询返回重复键值（如未去重的聚合结果或DISTINCT缺失） - 目标表主键/唯一约束失效（被禁用或未启用）
修复关键：把 ON 条件锚定在目标表的主键或唯一约束列上，例如 ON (t1.id = t2.id)。别贪图业务字段“好理解”，稳定性优先。
高并发下ORA-00001主键冲突，和权限无关但常被误判
在并发执行 MERGE INTO ... WHEN NOT MATCHED THEN INSERT 时，两个会话几乎同时判定“NOT MATCHED”，然后都尝试插入相同主键，触发 ORA-00001。这不是权限缺失，而是竞态条件。
比硬扛 MERGE 更稳的做法：
- 先用
INSERT INTO ... SELECT尝试插入，捕获ORA-00001后执行UPDATE - 确保
ON条件与INSERT的主键字段完全一致，且加WHERE子句双重防护（如WHEN NOT MATCHED THEN INSERT (...) VALUES (...) WHERE t2.id IS NOT NULL） - 避免在应用层做“先查再插”的逻辑，数据库层面的原子判断才可靠
真正容易被忽略的是：即使你拥有全部权限、ON 条件也基于主键，MERGE 在重启动（restartable）事务中仍可能因内部重试机制导致非幂等行为——这时必须加 WHERE 限定更新范围，否则一次失败重试可能把不该动的行也更新了。
