ORA-01031报错主因是缺少ALTER ANY MATERIALIZED VIEW权限，辅以基表及物化视图日志表的SELECT权限；三者缺一不可，且须显式授予、大小写敏感、跨schema需分别授权。
DBMS_MVIEW.REFRESH 手动执行报 ORA-01031: 权限不足，基本可以断定是当前用户缺少显式授予的权限——不是没装包、不是语法错、也不是物化视图本身坏了。
为什么 EXEC DBMS_MVIEW.REFRESH 会报 ORA-01031
手动刷新失败和自动刷新失败的权限根源一致，但表现更直接：dbms_mview.refresh 在内部调用 dbms_snapshot.refresh 时，会尝试修改物化视图元数据（如更新 snaptime$$、校验日志状态），这个动作触发了对 alter any materialized view 的硬性检查。
常见误区：
- 只授了
CREATE MATERIALIZED VIEW—— 这只能建 MV，不能刷 - 靠
CONNECT或自定义角色间接获得权限 —— JOB 和手动调用都无视角色，只认直接授权 - 以为
GRANT EXECUTE ON DBMS_MVIEW TO user就够了 —— 它只是让你能调过程，不等于有操作 MV 的权限
必须立即检查并授予的三个权限
缺一不可，且必须由 DBA 或拥有 GRANT ANY PRIVILEGE 的用户执行显式 GRANT：
-
ALTER ANY MATERIALIZED VIEW：最常漏掉、最关键的一项。没有它，任何刷新（FAST/COMPLETE/FORCE）都会在元数据校验阶段直接报ORA-01031 - 对所有基表（含远程表）的
SELECT权限：如果 MV 查询涉及SCHEMA_B.TAB_A，则当前用户必须有GRANT SELECT ON SCHEMA_B.TAB_A TO your_user - 对对应物化视图日志表（如
MLOG$_TAB_A）的SELECT权限：快速刷新时 Oracle 会读该表，权限缺失会导致ORA-00942或静默 fallback 到 COMPLETE，再因锁或资源卡住
验证权限是否真生效的最快方式
别只看 GRANT 语句有没有执行成功，要进数据库实测：
- 收回刚授的
ALTER ANY MATERIALIZED VIEW，再跑一次EXEC DBMS_MVIEW.REFRESH('MV_NAME')—— 应立刻复现ORA-01031，证明它是瓶颈 - 手动查日志表：
SELECT COUNT(*) FROM MLOG$_TAB_A;，若报ORA-00942，说明日志权限没给对，注意大小写和 schema 前缀 - 检查基表权限是否被意外 revoke：
SELECT privilege FROM dba_tab_privs WHERE grantee = 'YOUR_USER' AND table_name = 'TAB_A';，确保SELECT在列表中
容易被忽略的跨 Schema 场景
当物化视图和基表不在同一 schema 时，权限链极易断裂。例如：
- MV 在
USER_A下，基表在USER_B，日志也在USER_B下 - 你只给了
USER_A对USER_B.TAB_A的SELECT，但忘了USER_B.MLOG$_TAB_A的SELECT - 更隐蔽的是：日志表名大小写敏感，
MLOG$_tab_a和MLOG$_TAB_A是两个对象；Oracle 默认大写，但若建日志时用了双引号，就必须严格匹配
这种情况下，DBMS_MVIEW.REFRESH 可能先报 ORA-01031，也可能先卡住不动，取决于内部调用顺序——所以排查必须覆盖全路径，不能只盯第一个错误。
