必须用'OWNER.MVIEW_NAME'格式传参，否则跨用户刷新会因名称解析失败报ORA-00942；即使当前用户有权限或同名视图存在，Oracle也不自动匹配schema，且大小写敏感视图需双引号包裹。
必须用 'OWNER.MVIEW_NAME' 格式传参，不能只写视图名
跨用户刷新物化视图时，dbms_mview.refresh 的 list 参数必须显式带上 schema 名，否则会报 ora-00942: table or view does not exist——哪怕当前用户有 select 和 refresh 权限，oracle 仍按字面解析名称，不自动搜索其他 schema。
常见错误是写成：EXEC DBMS_MVIEW.REFRESH('EMP_MV', 'F')，而实际视图在 SCOTT 下；正确写法是：
EXEC DBMS_MVIEW.REFRESH('SCOTT.EMP_MV', 'F');
- 即使你在
SCOTT用户下执行，也不能省略SCOTT.——因为REFRESH内部不走当前 session 的默认 schema 解析逻辑 - 如果视图名含大小写或特殊字符（如
"My_MV_2024"），必须双引号包裹整个带 owner 的字符串：'"SCOTT"."My_MV_2024"' - 多个视图用逗号拼接，仍是纯字符串：
'SCOTT.EMP_MV,HR.DEPT_MV'，不能传数组、集合或换行
权限不是“有 SELECT 就够”，必须显式授予 REFRESH 系统权限
仅给目标用户 SELECT ON SCOTT.EMP_MV 不足以调用 REFRESH。Oracle 把刷新视为 DML 类操作，需独立授权：
- 跨 schema 刷新：需被授予
REFRESH ANY MATERIALIZED VIEW（DBA 级权限） - 仅刷特定 schema 下的 MV：可授
REFRESH MATERIALIZED VIEW，但必须在该 schema 下显式授权，例如：GRANT REFRESH MATERIALIZED VIEW ON SCOTT.EMP_MV TO APP_USER; -
CREATE MATERIALIZED VIEW权限 ≠ 刷新权限，两者完全独立
没授对权限时典型报错是 ORA-01031: insufficient privileges，注意检查 dba_sys_privs 而非 dba_tab_privs。
跨库刷新（DBLink）必须在目标库本地执行，且不能带 @dblink
如果你要刷新的是基于远程表（如 sales@site_b）创建的物化视图，关键约束是：刷新动作必须在物化视图所在的数据库上运行，且 list 参数中绝不能出现 @ 符号。
- 错误写法：
'SCOTT.SALES_MV@site_b'→ 直接报ORA-00942或ORA-02019 - 正确做法：登录到
site_b所指的**目标库**（即 MV 物理存放的库），然后执行EXEC DBMS_MVIEW.REFRESH('SCOTT.SALES_MV', 'C') - 远程基表的物化视图日志（
MLOG$）也只存在于远程库，本地无法扫描——所以跨库FAST刷新基本不可用，FORCE或COMPLETE是实际选择
ATOMIC_REFRESH => FALSE 在跨用户场景下极危险，别开
这个参数本意是提速：设为 FALSE 会让刷新走 TRUNCATE + INSERT /*+ APPEND */ 路径。但它在跨用户（尤其跨 schema）时容易触发隐性问题：
- 若物化视图依赖其他 schema 的对象（比如
REFRESH FAST依赖远程日志），ATOMIC_REFRESH => FALSE可能因权限隔离失败而中断，留下空表 - 事务边界变模糊：
TRUNCATE是 DDL，无法回滚；一旦中间出错，MV 表已清空且无数据可恢复 - 默认值是
TRUE，它用MERGE或逐条INSERT/UPDATE/DELETE，慢但可控——跨用户刷新时应坚持用默认值
真正影响性能的往往是日志缺失、网络延迟或锁竞争，而不是这个参数；盲目关掉它，反而把“可恢复的慢”变成“不可逆的坏”。
