5

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

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

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

4

1 回答 1

2

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

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;
于 2012-10-23T22:26:18.017 回答