物化视图卡在REFRESHING状态需先查v$session和v$locked_object定位锁源，根本原因是atomic_refresh=TRUE导致事务级锁、undo膨胀及行锁冲突；应显式设atomic_refresh=>FALSE启用TRUNCATE+INSERT，并验证日志完整性与MV编译态。
物化视图卡在REFRESHING状态，先查锁和会话
refreshing不是正常运行态，而是事务或进程卡住的信号。直接看v$session和v$locked_object比等超时更有效。
- 运行
SELECT sid, serial#, sql_id, event, state, seconds_in_wait FROM v$session WHERE status = 'ACTIVE' AND program LIKE '%DBMS_MVIEW%'，确认是否真在执行，还是卡在enq: TX - row lock contention或db file sequential read - 查锁源：
SELECT object_name, locked_mode FROM v$locked_object lo JOIN dba_objects ao ON lo.object_id = ao.object_id，重点看基表、MLOG$_xxx日志表、物化视图本身是否被锁 - 若发现持有锁的会话
sql_id为空或event长期为SQL*Net message from client，大概率是客户端断连但服务端事务未清理，需人工ALTER SYSTEM KILL SESSION
atomic_refresh=TRUE是REFRESHING卡死的高频原因
默认atomic_refresh => TRUE会让整个刷新包在一个事务里：DELETE旧数据 → INSERT新数据 → COMMIT。百万级以上数据下，这过程极易撑爆undo、触发ORA-01555，或因tx锁阻塞其他DML而反向拖慢自己。
- 手动刷新必须显式传参：
DBMS_MVIEW.REFRESH('MV_SALES', atomic_refresh => FALSE)，改用TRUNCATE+INSERT模式，跳过redo/undo，锁粒度降到表级且只在TRUNCATE瞬间 - 定时任务（
DBMS_JOB或DBMS_SCHEDULER）中，不能依赖默认值，必须在调用封装过程时硬编码该参数 - 副作用是刷新过程中物化视图短暂为空，应用层需能容忍；若不能，得改用分区交换方案，而非强行保“始终有数据”
并行刷新没加速反而更卡？检查parallelism与日志结构匹配性
parallelism > 0不等于自动变快。Oracle 11g中，并行刷新实际生效的前提是：物化视图日志支持并行FAST，且底层资源不争用。
- 查日志是否带
SEQUENCE$$和主键：SELECT ROWIDS, PRIMARY_KEY, SEQUENCE FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'，三项都需为YES，否则并行时会静默退化为串行COMPLETE -
parallelism建议从2起步，再试4；超过CPU_COUNT * 2易引发enq: PS - contention等待，压垮PX server池 - 若基表走DBLink，
parallelism只作用于本地端计算，远程仍串行，收益极低——此时不如关并行，专注优化远程查询
REFRESHING卡住后别急着删日志或重建MV
盲目清空MLOG$_xxx或DROP MATERIALIZED VIEW可能破坏依赖链，尤其当多个MV共用同一日志时。
- 先确认日志归属：
SELECT master, log_table FROM user_mview_logs，若该日志只被当前MV使用，才可考虑TRUNCATE TABLE mlog$_your_master_table - 清空后必须立刻手动执行一次
DBMS_MVIEW.REFRESH，否则日志不会重新开始记录变更，后续FAST仍失败 - 若
STALENESS = 'UNUSABLE'或STATUS = 'NEEDS_COMPILE'，先ALTER MATERIALIZED VIEW mv_name COMPILE，再刷新；否则REFRESH会直接报错退出
REFRESHING卡住的本质，往往不是SQL慢，而是事务语义（atomic_refresh）、资源调度（parallelism）、元数据状态（日志完整性、MV编译态）三者错配。单独调优任一参数都不够，必须同步验证这三者的实际生效情况。
