数据仓库中物化视图的刷新策略

Question

我有一个系统，它的物化视图包含大约 10 亿个项目，在一致的两小时内，我需要更新大约 2 亿个（占记录的 20%）。我的问题是我的物化视图的刷新策略应该是什么？截至目前，它是间隔刷新的。我很好奇在间隔刷新和从不刷新和用新的物化视图重命名/替换旧物化视图之间的性能影响。根本问题是甲骨文使用的索引会产生大量的重做。任何建议表示赞赏。

更新
由于有些人似乎认为这是题外话，我目前的观点是做以下事情：

创建一个调用一系列 PL/SQL（我保证是编程语言）函数的 Oracle 调度链，以伪并行方式刷新物化视图。然而，就好像我落入了某种 DBA 的位置一样，我希望通过算法和/或一些代码来解决数据问题。

Answer 1

好的，这就是我想出的解决方案，您的里程可能会有所不同，事后对任何反馈表示赞赏。总体策略是执行以下操作：

1) 利用 Oracle 调度器利用链（作业）的并行执行
2) 使用视图（常规类型）作为从应用程序到数据库的接口
3）依赖物化视图按如下方式构建

 create materialized view foo  
    parallel  
    nologging  
    never refresh  
    as  
    select statement

根据需要使用以下内容：

   create index baz on foo(bar) nologging

这样做的好处是我们可以在删除之前在后台构建物化视图，然后按照步骤 2 中的描述重新创建视图。现在的好处是创建动态命名的物化视图，同时保持视图具有相同的名称。关键是在新的物化视图完成之前不要吹走原来的物化视图。这也允许快速下降，因为需要最少的重做。这可以在 5 分钟内创建约 10 亿条记录的物化视图，这满足了我们每 30 分钟“刷新”一次的要求。此外，这可以在单个数据库节点上处理，因此即使硬件受限，也是可能的。

这里有一个 PL/SQL 函数会为你创建它：

CREATE OR REPLACE procedure foo_bar as
foo_view varchar2(500) := 'foo_'|| to_char(sysdate,'dd_MON_yyyy_hh_mi_ss');
BEGIN
 execute immediate
 'Create materialized view '||  foo_view || '
  parallel
  nologging
  never refresh
  as
  select * from cats';
END foo_bar;