物化视图刷新触发library cache lock的根本原因是atomic_refresh=>true导致truncate（ddl），需加独占库缓存锁；改用atomic_refresh=>false可降为行级锁，但须确保物化视图真正支持fast刷新且日志完备。
物化视图刷新为什么会触发library cache lock
根本原因不是物化视图本身，而是dbms_mview.refresh调用时默认启用atomic_refresh => true，导致oracle先执行truncate再insert。这个truncate是ddl操作，必须在目标物化视图表上加exclusive library cache lock——所有其他会话（包括查询该物化视图、甚至查其基表的sql）都会卡在library cache lock等待上，直到刷新完成。
典型现象：v$session里看到大量会话event = 'library cache lock'，blocking_session指向刷新会话；v$locked_object中锁模式为6（exclusive），对象正是物化视图表名。
绕过TRUNCATE锁：改用atomic_refresh => FALSE
把atomic_refresh => TRUE改成atomic_refresh => FALSE，Oracle就不再truncate，而是走DELETE + INSERT路径，锁粒度降为行级（ROW EXCLUSIVE），业务DML和查询基本不受影响。
- 必须满足前提：物化视图真支持FAST刷新，且已建好对应物化视图日志（
MLOG$_xxx） - 执行示例：
DBMS_MVIEW.REFRESH('MV_SALES', method => 'F', atomic_refresh => FALSE) - 如果物化视图定义含聚合、连接或不满足FAST条件，此参数会静默退化为COMPLETE刷新，反而更慢更锁——不能只看创建语句写了
REFRESH FAST，得查实际能力
验证物化视图是否真支持FAST刷新
别信创建语句，查Oracle运行时认可的状态：
- 查
user_mviews：SELECT mview_name, fast_refreshable FROM user_mviews WHERE mview_name = 'MV_SALES'，返回值必须是'FAST'（不是'FAST_SNAPSHOT'或'NO'） - 查依赖完整性：
SELECT * FROM user_mview_analysis WHERE mview_name = 'MV_SALES'，重点关注capable_flag = 'N'的项，比如缺失日志、主键变更、远程表等 - 确认日志存在：
SELECT log_table FROM user_mview_logs WHERE master = 'SALES'，结果为空说明日志没建或已失效
刷新耗时长仍会引发间接阻塞
即使用了atomic_refresh => FALSE，若刷新本身耗时几十秒以上，delete/insert会积累大量undo，其他会话读取旧版本数据时需构造一致性读镜像，可能卡在read consistency等待，表现就像“被锁住”。
- 监控真实耗时：
SELECT start_time, end_time, elapsed_seconds FROM user_mview_refresh_times WHERE name = 'MV_SALES' ORDER BY start_time DESC - 避免在业务高峰执行，尤其当物化视图基表很大、或网络延迟高（跨库刷新）时
- 如果刷新时间持续偏长，优先排查基表是否有未提交事务、索引是否失效、统计信息是否陈旧——这些会让FAST刷新退化为慢速路径
真正难处理的点不在参数开关，而在“FAST”二字是否名副其实。很多环境里物化视图日志长期未维护，或基表结构变更后没重建日志，表面配置都对，一刷就锁表。得动手查user_mview_analysis，而不是只改参数。
