DBMS_SCHEDULER作业必须显式绑定资源组才能生效；DBMS_JOB已废弃，不支持优先级、CPU限制或资源分组，所有作业默认挤在OTHER_GROUPS（仅5% CPU），导致NEXT_DATE滞后、BROKEN为TRUE却无错误日志。
DBMS_SCHEDULER 作业必须显式绑定资源组才能生效
Oracle 12c+ 中，DBMS_JOB 已废弃，它不支持优先级、CPU 限制或资源分组。如果你还在用 DBMS_JOB 提交刷新任务，哪怕设置了高频率，也根本无法抢占调度器资源——所有作业默认挤在 OTHER_GROUPS（仅分配 5% CPU），导致 DBA_JOBS 里 NEXT_DATE 滞后数小时，BROKEN 字段为 TRUE 却查不到错误日志。
实操建议：
- 先停掉旧作业：
DBMS_JOB.REMOVE(<job_number>)</job_number>，再确认USER_JOBS为空 - 创建专用消费者组：
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('MV_HIGH_PRIORITY')，并用CREATE_PLAN_DIRECTIVE分配至少 30% CPU - 新建 scheduler 作业时，必须传入：
attribute => 'RESOURCE_CONSUMER_GROUP', value => 'MV_HIGH_PRIORITY' - 避免用模糊的
REPEAT_INTERVAL => 'FREQ=DAILY'；改用精确时间点：START_DATE => SYSTIMESTAMP + INTERVAL '5' SECOND
DBMS_MVIEW.REFRESH 的 parallelism 和 atomic_refresh 参数不能省略
即使调度及时，单次刷新慢仍会拖垮整体延迟，尤其是 COMPLETE 刷新——默认串行执行，且内部走 TRUNCATE + INSERT /*+ APPEND */，锁表时间长、I/O 压力大。这两个参数直接影响刷新耗时和业务影响范围。
实操建议：
-
parallelism => 4可显著缩短执行时间，但值不能超过PARALLEL_MAX_SERVERS当前设置（查V$PARAMETER） -
atomic_refresh => FALSE强制走TRUNCATE + INSERT，快但锁表；设为TRUE（默认）则用MERGE，慢但支持并发 DML - 对非核心报表 MV，推荐组合：
method => 'C', parallelism => 4, atomic_refresh => FALSE - 若基表有大量 delete 操作，
atomic_refresh => TRUE可能引发大量 undo，需提前评估
刷新延迟高，90% 问题出在 DBA_REFRESH 和 DBA_MVIEWS 状态误判
很多人一看到查询慢就去调优 SQL，结果发现 DBA_MVIEWS.staleness = 'STALE'、last_refresh_date 几天没更新，却忽略真正瓶颈：刷新作业根本没跑起来。关键不是 SQL 慢，是作业卡在队列里。
实操建议：
- 查刷新组状态：
SELECT NAME, REFRESH_METHOD, STALENESS FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV' - 查刷新作业是否挂起：
SELECT NAME, NEXT_DATE, BROKEN, WHAT FROM DBA_JOBS WHERE WHAT LIKE '%dbms_mview.refresh%' - 查调度器容量：
SHOW PARAMETER job_queue_processes，低于 10 就别指望高并发刷新不排队 - 如果
DBA_REFRESH中对应刷新组的NAME显示DELAYED或长期无新记录，说明调度器已饱和，必须切到DBMS_SCHEDULER+ 资源组
FAST 刷新依赖物化视图日志，但日志本身可能成性能瓶颈
启用 FAST 刷新看似高效，但每次基表 DML 都要写日志表，尤其在高频 insert/update 场景下，MLOG$_xxx 表可能成为热点，反而拖慢主业务。这不是配置错，而是设计权衡没做清。
实操建议：
- 检查日志表大小和索引：
SELECT segment_name, bytes/1024/1024 MB FROM dba_segments WHERE segment_name LIKE 'MLOG%' - 日志表必须有
ON COMMIT索引（如CREATE INDEX idx_mlog ON mlog$_t (snaptime$$)），否则刷新时全表扫描 - 若基表变更集中在少数列，日志只需包含这些列：
WITH ROWID, SEQUENCE(col_a, col_b)，别全字段冗余 - 对写多读少场景，
FAST反而不如定期COMPLETE+parallelism更稳
