物化视图刷新可怕的性能下降答案

【问题标题】：Materialized view refresh terrible performance degradation物化视图刷新可怕的性能下降
【发布时间】：2016-05-18 02:31:50
【问题描述】：

我有物化视图（它使用连接、WITH、分区；查询返回大约 4200 万 行），上面有 2 个简单索引。仅使用完全刷新。

第一次刷新工作正常（大约需要 100 分钟），但第二次刷新工作几天后未能完成。

我还删除了索引并重新运行测试。它工作正常。以下是所有结果（会话统计中的时间和重做条目）：

1) 没有索引，首先运行时间：72分钟 redo: 4200万（接近行号）

2) 没有索引，第二次运行时间：106分钟重做：8400 万（4200 万删除全部，4200 万插入新）

3) 有 2 个索引，第一次运行时间：99分钟重做：1.26 亿（行 4200 万，每个索引 4200 万）

4) 有 2 个索引，第二次运行时间：48小时后失败重做：4.53 亿失败时（我不知道为什么这么大）

Oracle 版本：11g Enterprise Edition Release 11.2.0.3.0

该问题在不同的实例和服务器上重现。我没有可以正常工作的服务器。我认为这是某种错误，但找不到类似的东西

【问题讨论】：

有问题吗？（更重要的是，如果有问题，鉴于您提供的有关您使用的表、索引和查询的信息缺乏，我们有什么办法可以回答吗？）
我无法复制 SQL 查询，但它本身执行了大约 30 分钟。所以我们需要 30 分钟来选择数据，大约需要 40-60 分钟来插入它。问题是“为什么重建索引比 bulding 慢 50 倍，并且需要异常巨大的重做大小？”索引是一个简单的 varchar2 列。
@Vladislav 感谢您的提示，即在没有索引的情况下刷新速度要快得多，而查询这些物化视图仍然比单独运行复杂查询要快得多！

标签： oracle performance indexing materialized-views

【解决方案1】：

需要注意的是，在版本 10 和 11 之间，Oracle 将 dbms_mview.refresh() API 的可选“atomic_refresh”参数的默认值从 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 不包含重建数据，这可能会给用户带来问题查询它。做一些研究，弄清楚您的业务需求是什么，然后从那里开始。您还可以删除索引，进行刷新，然后重新创建索引以加快速度。

【讨论】：

如果索引会被删除，那么使用 MV 是没有意义的
如果您只是为了重建而删除它们，然后在之后立即重新创建它们，重建将运行得更快并且重做更少，最终结果仍然是一个更高效的索引物化数据集而不是运行时的复杂查询。
是的，重建索引只需要6分钟，但重建数据需要60分钟，在此期间将无法进行快速数据搜索。
嗯，完全重建大型数据集确实需要时间。也许您需要重新评估并查看基于分区更改跟踪或其他机制的快速刷新 - 因为不必要地重新生成大型数据集总是会成为性能问题。