为什么删除 MVIEW 会触发完全刷新？

Question

我刚刚在 Oracle 中创建了一个物化视图，但意识到我使用了错误的脚本，所以我想再次删除 MVIEW。

MVIEW 是用这样的语句创建的：

create materialized view foobar
  refresh start with trunc(sysdate) + 1/8  next sysdate + interval '8' hour
as
select ...
from ...;

创作花了一些时间。

现在在意识到这是我运行的错误脚本之后：

drop materialized view foobar;

这也运行了一段时间。我首先认为这可能是由于某些锁定或其他会话阻止了这一点，但不是：当我查询时，v$session我看到我的drop语句实际上触发了 mview 的完全刷新：

用户名 | SID | 序列号 | 节目 | 状态 | SQL_ID | SQL_TEXT
----------+------+---------+-------------- ----+--------+---------------+------------ -------------------------------------------------- ---
我的用户 | 第294话 29131 | oracle@hostname (J002) | 活跃 | 6snjgrzbtynyc | INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "MY_USER"."FOOBAR" select .....

事实上，drop materialized view运行的时间与create.

所以我的问题是：当我删除物化视图时，为什么 Oracle 会触发完全刷新？

环境：Oracle 11.2.0.3 64bit

---

^{PS：我觉得别名indexed-view为materialized-view是错误的。尽管两者都引用了相同的基本概念，但它们是 Microsoft 和 Oracle 使用的不同名称。对 Oracle 中的物化视图感兴趣的人可能对 SQL Server 中的索引视图不感兴趣。但我不知道如何删除这个别名}

Answer 1

在隔离环境中运行一些测试后，拉吉似乎是对的：我在等待时看到的刷新后台作业DROP不是由DROP. 据我所知，这是由创建 mview 期间提供的刷新设置引起的。

看起来

refresh start with trunc(sysdate) + 1/8  next sysdate + interval '8' hour

与隐式一起build immediate导致 mview 在创建期间刷新，然后在创建完成后立即刷新。

显然start with trunc(sysdate) + 1/8导致了这一点。跑步时

create materialized view foobar 
   BUILD DEFERRED
   refresh start with trunc(sysdate) + 1/8  next sysdate + interval '8' hour
as
select ...
from ...;

该create语句很快完成，当我查看活动会话时，我确实看到一个进行刷新的后台会话。