sql - 数据仓库中物化 View 的刷新策略

Question

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

更新
由于有些人似乎认为这是题外话，我目前的观点是执行以下操作:

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

Answer 1

好的，这是我想出的解决方案，您的里程可能会有所不同，事后感谢您的任何反馈。总体策略是执行以下操作:

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

 create materialized view foo  
    parallel  
    nologging  
    never refresh  
    as  
    select statement

根据需要使用以下内容:

   create index baz on foo(bar) nologging

这样做的好处是我们可以在删除之前在后台构建物化 View ，然后按照步骤 2 中的描述重新创建 View 。现在的好处是创建动态命名的物化 View ，同时保持 View 具有相同的名称。关键是在新的物化 View 完成之前不要吹走原来的物化 View 。这也允许快速下降，因为需要最少的重做。这可以在 5 分钟内创建约 10 亿条记录的物化 View ，这满足了我们每 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;