Transactions DBMS_MVIEW.REFRESH是否在执行时在MV使用的表中插入和更新块？

我认为这个问题很清楚，但仍然有一个例子：

假设我有一个MV，名为“MY_MATERIALIZED_VIEW”，使用

CREATE MATERIALIZED VIEW MY_MATERIALIZED_VIEW PARALLEL PARTITION BY RANGE (some_date)
    (
      PARTITION RESULT_MATRIX_V_2012 VALUES LESS THAN (TO_DATE('01/01/2013','dd/MM/yyyy')),
      PARTITION RESULT_MATRIX_V_2013 VALUES LESS THAN (TO_DATE('01/01/2014','dd/MM/yyyy')),
      PARTITION RESULT_MATRIX_V_2017 VALUES LESS THAN (MAXVALUE)
    )
    NOCOMPRESS
    LOGGING
    BUILD DEFERRED
    USING INDEX TABLESPACE XXISLT_INDEX
    REFRESH FAST ON COMMIT
    USING DEFAULT LOCAL ROLLBACK SEGMENT
    DISABLE QUERY REWRITE AS
 SELECT c1,c2
 FROM SOME_TABLE;

然后我执行

EXEC DBMS_MVIEW.REFRESH('MY_MATERIALIZED_VIEW','C');

现在让我们假设最后一条指令大约需要4个小时才能完成，在这之前，我尝试这样做

update SOME_TABLE SET c1 = 4 where c2 = 6;

会发生什么？有些桌子被堵住了？ 我的怀疑是因为我没有找到任何清晰的文件

---

您好，

更新将成功

物化视图刷新与任何其他读取器进程一样。从表中读取的进程不会阻止任何其他会话读取该表中的数据。和其他读取器一样，物化视图将看到插入操作开始时存在的数据。换句话说，物化视图将反映更新之前的数据

---

当然，如果您实际创建了所描述的物化视图，则不需要调用

dbms\u mview.refresh

，因为它被设置为在刷新时提交。在这样一个物化视图上进行完全刷新通常也没有多大意义，因为您可以进行增量刷新。如果您能够创建物化视图，这意味着您在

某些表上有一个物化视图日志

，在这种情况下，刷新过程通常使用物化视图日志中的数据，而不是表中的数据。

您能添加一些引用吗？？事实上，我确实做了测试，在刷新完成之前，MV中使用的表被阻塞（测试持续时间超过了配置的超时时间），顺便说一句，因为我使用了BUILD DEFERRED，所以需要刷新