DB Link断开时COMPLETE刷新会无限等待而非超时，根本原因是Oracle Net无SQL级超时机制；唯一可行方案是用DBMS_SCHEDULER包装刷新并设置max_run_duration强制中断，同时前置DB Link连通性检查。
DB Link断开时COMPLETE刷新会卡住，不是超时而是无限等待
Oracle在执行DBMS_MVIEW.REFRESH跨库物化视图（含@dblink）时，若DB Link底层连接中断或远程库不可达，不会抛出ORA错误并退出，而是持续重试——表现为会话长期处于SQL*Net message from dblink等待事件，V$SESSION中STATE为WAITING，EVENT为SQL*Net message from dblink，且无超时控制。这不是配置缺失，是Oracle原生行为。
根本原因：跨库刷新本质是本地会话发起远程SQL执行（如SELECT * FROM t@remote_link），网络层由Oracle Net stack接管，而Oracle Net默认不设SQL级超时，只依赖OS TCP keepalive（通常2小时起），远超运维容忍窗口。
- 不能靠
SQLNET.EXPIRE_TIME解决：该参数仅检测空闲连接断连，对正在执行的查询无效 -
OPEN_LINKS和OPEN_LINKS_PER_INSTANCE参数只限制并发链路数，不影响单次等待 - DB Link本身无法配置查询级timeout，
CREATE DATABASE LINK语法不支持TIMED_OUT或MAX_WAIT子句
唯一可行方案：用DBMS_SCHEDULER包装刷新，并设置job级超时
绕过挂起的核心思路是把刷新操作从“同步阻塞调用”转为“带时限的异步任务”，利用DBMS_SCHEDULER的max_run_duration强制中断。
操作步骤：
- 先确认调度器已启用：
SELECT value FROM v$parameter WHERE name = 'job_queue_processes'，确保值 > 0（12c+建议≥1000） - 创建作业时必须显式指定
max_run_duration，单位秒，例如300秒（5分钟）：BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name => 'REFRESH_MV_REMOTE_TIMEOUT', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN DBMS_MVIEW.REFRESH(''SCOTT.MV_REMOTE'', method => ''C''); END;', start_date => SYSTIMESTAMP, repeat_interval => NULL, enabled => FALSE, max_run_duration=> 300 ); END; - 启用前务必测试：运行
EXEC DBMS_SCHEDULER.ENABLE('REFRESH_MV_REMOTE_TIMEOUT')，再手动触发EXEC DBMS_SCHEDULER.RUN_JOB('REFRESH_MV_REMOTE_TIMEOUT', use_current_session => FALSE)，观察是否在300秒后自动STOPPED - 注意：作业失败后状态变为
BROKEN，需手动DBMS_SCHEDULER.ENABLE恢复；不要依赖AUTO_DROP => TRUE，否则超时后作业消失，无法审计
DB Link连通性必须前置验证，不能依赖刷新时才发现
即使加了job超时，也不能把DB Link健康检查甩给调度器。因为DBMS_MVIEW.REFRESH在真正执行远程查询前，会先尝试解析、权限校验、统计信息收集等本地动作，这些阶段失败仍会报错（如ORA-02069、ORA-02041），但不触发max_run_duration——超时机制只对“正在执行的job”生效。
安全做法是：在调度作业启动前，插入一个独立的连通性检查步骤：
- 写一个轻量函数，只查远程
DUAL并设短超时：CREATE OR REPLACE FUNCTION remote_link_up(p_dblink VARCHAR2) RETURN BOOLEAN IS l_dummy VARCHAR2(1); BEGIN EXECUTE IMMEDIATE 'SELECT ''X'' FROM DUAL@' || p_dblink INTO l_dummy; RETURN TRUE; EXCEPTION WHEN OTHERS THEN RETURN FALSE; END; - 在job_action中组合判断：
IF remote_link_up('REMOTE_LINK') THEN DBMS_MVIEW.REFRESH(...); ELSE RAISE_APPLICATION_ERROR(-20001, ''DB Link down''); END IF; - 关键点：这个函数本身不带超时，所以必须配合
DBMS_SCHEDULER的max_run_duration一起用，双重保险
COMPLETE刷新本身无法降级为“部分成功”，失败即全量失效
跨库场景下没有FAST，只有COMPLETE，意味着每次刷新都是原子性的全量重拉。一旦DB Link在SELECT过程中断开，整个刷新事务回滚，物化视图状态保持STALE，不会残留部分数据或中间状态。
这意味着你无法通过“分页拉取”或“按分区刷新”来规避风险——Oracle不支持对跨库MV做PARTITION子句或WHERE条件过滤刷新。所有数据都得走一遍SELECT * FROM t@dblink，网络抖动、远程库负载高、大结果集OOM，都会导致同一结果：卡住或失败。
最容易被忽略的是：DBMS_MVIEW.REFRESH返回成功（无异常），不代表数据已更新。必须紧接着查USER_MVIEWS.STALENESS字段，值为UNDEFINED或STALE才说明失败，FRESH才是真成功。别只看PL/SQL块有没有报错。
