我有物化视图（它使用连接，WITH，分区依据;查询返回 42 mln 行），上面有2个简单的索引。仅使用完全刷新。
第一次刷新工作正常（需要约100分钟），但第二次刷新工作几天但未能完成。
我还删除了索引并重新运行测试。它工作正常。 以下是所有结果（会话统计信息中的时间和重做条目）：
1）没有索引，首先运行 时间：72分钟 重做： 42毫升（接近行号）
2）没有索引，第二次运行 时间：106分钟 重做： 8400万（42％用于删除全部，42％用于插入新用途）
3）有2个索引，首先运行 时间：99分钟 重做： 126毫升（行为42毫升，每个索引为42毫升）
4）有2个索引，第二次运行 时间：48小时后失败 重做： 453万失败时（我不知道它为何如此巨大）
Oracle版：11g企业版11.2.0.3.0版
该问题在不同的实例和服务器上重现。我没有正常工作的服务器。我认为这是某种错误，但无法找到类似的东西
答案 0 :(得分：1)
有一点需要注意，在版本10和11之间，Oracle更改了可选＆＃34; atomic_refresh＆＃34;的默认值。 dbms_mview.refresh（）API的参数从FALSE变为TRUE。
如果atomic_refresh = TRUE，则将通过DELETE / INSERT完成全部刷新。如果atomic_refresh = FALSE那么，如果可能，Oracle将通过具有并行DML的TRUNCATE / INSERT进行刷新。更快，但有以下警告：但是，如果你一次刷新多个mview，那么你需要考虑这个因为atomic_refresh = TRUES确保所有刷新都发生在一个事务中，FALSE不会 - 可能有问题。
编辑：我的不好，行为的改变发生在Oracle 9和10之间。不是10和11.还有副作用，截断/插入意味着MVIEW不包含重建的数据，这可能对用户有问题查询它。做一些研究，找出你的业务需求，并从那里开始。您也可以删除索引，执行刷新，然后重新创建索引以加快速度。