物化视图刷新必须授予用户对SYS.DBMS_MVIEW包的EXECUTE权限（直接授权，不可通过角色），且需同时具备基表及对应物化视图日志表的SELECT权限；DBMS_SCHEDULER作业运行用户须在启用前获得这些权限，否则刷新失败且日志可能误导。
物化视图刷新用户必须有 EXECUTE 权限，不是 CREATE MATERIALIZED VIEW
很多人误以为给用户授了 CREATE MATERIALIZED VIEW 就能刷新，其实这是创建权限，和刷新完全无关。真正执行 DBMS_MVIEW.REFRESH 需要的是对 DBMS_MVIEW 包的 EXECUTE 权限——而且必须是直接授予，不能通过角色间接获得（Oracle 调度作业不识别角色权限）。
- 正确授权方式：
GRANT EXECUTE ON SYS.DBMS_MVIEW TO refresh_user; - 如果用 DBMS_SCHEDULER 创建作业，作业运行用户（即
job_action中语句的执行上下文）必须拥有该权限，不是创建作业的用户 - 若刷新涉及跨数据库链接（
@dblink），还需确保该用户对远程基表有SELECT权限，且 dblink 所用账号也具备对应权限
基表和物化视图日志的 SELECT 权限缺一不可
刷新时，DBMS_MVIEW.REFRESH 会读取基表本身，以及对应的物化视图日志表（如 MLOG$_sales）。哪怕物化视图和基表都在同一 schema 下，只要刷新用户不是所有者，就必须显式授权。
- 查基表：
GRANT SELECT ON owner.sales TO refresh_user; - 查日志表：
GRANT SELECT ON owner.MLOG$_sales TO refresh_user;（注意：日志表名是系统生成的，需从USER_MVIEW_LOGS或DBA_MVIEW_LOGS中确认） - 如果基表无主键但用了
WITH ROWID日志，仍需SELECT权限；否则FAST刷新会静默退化为COMPLETE，甚至报 ORA-12008
ON COMMIT 刷新用户还要额外注意事务一致性权限
如果物化视图定义为 REFRESH FAST ON COMMIT，刷新发生在基表事务提交瞬间，此时执行上下文就是基表的 DML 用户。这意味着：该用户不仅要有基表 SELECT 权限，还必须被授予 ALTER ANY MATERIALIZED VIEW（若刷新目标不是自己拥有的 MV）或 ALTER MATERIALIZED VIEW（若是自己 schema 下的 MV）。
- 常见失败现象：DML 成功、COMMIT 也成功，但 MV 数据没更新，查
DBA_MVIEWS发现LAST_REFRESH_DATE没变 —— 很可能就是缺少ALTER权限 -
ON COMMIT不支持跨库、不支持含聚合/分析函数的查询，这些限制与权限无关，但常被误判为权限问题
用 DBMS_SCHEDULER 刷新时，权限必须在作业启用前就位
DBMS_SCHEDULER 作业一旦 enabled => TRUE，就会按计划调用 DBMS_MVIEW.REFRESH。如果此时权限缺失，作业状态会变成 FAILED，且错误日志里只显示 “PL/SQL procedure successfully completed” 这类误导性信息——实际是权限不足导致内部异常被吞掉。
- 验证方法：手动以作业所属用户身份执行一次
BEGIN DBMS_MVIEW.REFRESH('mv_sales_daily', 'F'); END;，看是否报 ORA-01031 - 权限必须在
CREATE_JOB之后、ENABLE之前授予，否则作业首次运行即失败，后续也不会自动重试 - 不要依赖
CREATE ANY MATERIALIZED VIEW代替EXECUTE ON DBMS_MVIEW，前者管不了刷新动作
SELECT 或一个 EXECUTE，刷新就会静默失效。 
