在物化视图中性能下降 在索引激活的情况下完全刷新。

Question

问题：在索引处于活动状态时，完全刷新期间性能明显下降。 在完全刷新的过程中，当索引被激活时，性能会显著下降。我不太清楚为什么索引在完全刷新期间处于活跃状态会导致性能的显著差异。目前我们的数据仓库存在过度索引的问题，但我惊讶地看到，在完全刷新时，即使只有一个活动索引与没有活动索引，也会出现巨大的性能下降。

Oracle 12c版本

研究。 物化视图刷新可怕的性能下降我在SO上找到了这个，但它不一定能回答我的问题，为什么索引会导致性能下降。我可能会继续按照建议放弃索引，并在完全刷新后重建，但我仍在试图找出WHY。

示例性能测试。 我有很多MV，但这是我测试MV和相关费用的一个例子。我已经测试了大约10个MV，它们都显示出相同的模式。请注意，我修改了代码，删除了所有的对象名称。

在所有索引激活的情况下。

exec dbms_mview.refresh('MY_MV_TEST','C');

SQL Developer报告的实时执行时间： ~153秒

获得性能。

SELECT elapsed_time, log_purge_time
FROM dba_mvref_stats
....

elapsed_time = 151log_purge_time = 1。

ALTER INDEX IX_MY_MV_TEST_1 UNUSABLE;
....
ALTER INDEX IX_MY_MV_TEST_13 UNUSABLE;

重新运行完成刷新。

exec dbms_mview.refresh('MY_MV_TEST','C');

从dba_mvref_stats中获取统计数据。

elapsed_time = 27log_purge_time = 1。

我有点吃惊，于是我试了1个1个，每次只激活1个索引。每个索引都报出了33的elapsed_time和2的log_purge_time（我觉得有点奇怪，他们报的时间也都一样）。还有一些其他的MV也从300s到40s。到目前为止，我只在我们数据仓库的一小部分子集上进行了测试，我假设我们一些较大的MV也会出现同样的结果。根据SQL开发者的报告，重建索引只需要11s。

MV DDL。重命名所有对象需要一些时间 但如果有必要的话，我会在必要的情况下进行重命名 目前，这是这个特殊的MV定义的总体俯视图。在SELECT子句中，只有列，几个case语句，还有几个substr()，和cast()。

CREATE MATERIALIZED VIEW MY_MV_TEST 
BUILD DEFERRED 
USING INDEX REFRESH FORCE ON DEMAND 
USING DEFAULT LOCAL ROLLBACK SEGMENT
USING ENFORCED CONSTRAINTS AS
SELECT column1, column2, CASE..., SUBSTR(..), CAST()...
FROM mv1, mv2, mv3
WHERE mv1.column1 = mv2.column1
AND mv1.column1 = mv3.column1
AND ... (other simple conditions using the equality operator)

另外请注意，我测试过的所有MV都是能够refreshh fast的。DBMS_MVIEW.EXPLAIN_MVIEW显示它们都是能够REFRESH FAST的。我使用COMPLETE REFRESH只是为了测试。

Answer 1

请检查一下平行运行刷新是否有帮助。

ALTER SESSION ENABLE PARALLEL DML;

另外，把刷新切换到非原子状态。

EXEC dbms_mview.refresh(list=>'MY_MV_TEST', method=>'C', atomic_refresh=>false);

然后Oracle会禁用索引，自动刷新数据并重建索引，这在大多数情况下会更快。