【问题标题】:Fast refresh materialized view based on non-fast refresh view基于非快速刷新视图的快速刷新物化视图
【发布时间】:2011-09-20 05:38:52
【问题描述】:

我发现我可以有两个表并根据这些表连接创建一个fast refresh on commit materialized view

但是,我想做的是根据以下内容制作fast refresh on commit 物化视图:

(1) 加入一个表
(2) 一个complete refresh on demand物化视图,它本身是基于其他视图(即普通视图)的。

当我尝试这样做时,我收到错误 ORA-12053,它谈到了 from 子句中的条目相互依赖,即使它们显然不依赖。

我可以通过将 (2) 替换为普通表来解决此问题,并且只需在该表中进行批量插入,而不是刷新物化视图。但是,如果没有必要,我宁愿不这样做。

我将尝试做一个说明错误的最小示例,但是如果您能告诉我我想做的事情是可能的(最好是通过示例)还是不可能的,那就太好了。

【问题讨论】:

  • 这是一个有趣的问题,请添加示例。

标签: sql oracle materialized-views


【解决方案1】:

按照这些事实来理解错误。

  1. Fast Refresh on Commit 物化视图按行刷新 行基于对基表所做的更改。
  2. Refresh Complete on Demand 物化视图被刷新 截断目标表并重新插入所有内容。
  3. 无法刷新上部物化视图,因为 oracle 无法跟踪表 2 上的更改(即刷新完成 物化视图。)

【讨论】:

  • (1)表和(2)complete refresh on demand物化视图都有物化视图日志,所以我不确定为什么我不能从物化视图快速刷新但可以快速如果我只是截断表并手动重新插入,则刷新?
  • 您可以在截断并提交后快速刷新,但“截断”不会在目标物化视图上复制。您只会在物化视图中获得插入。这在嵌套的物化视图中是不允许的,因为这很奇怪。它不会反映基表数据。
【解决方案2】:

嵌套物化视图有一些限制。我在this blogpost 中描述了它们。 ORA-12053 是不满足嵌套 MV 的第一个限制的结果。使底层 MV 更复杂(连接、聚合或联合所有 MV)是一种解决方案。

问候,
抢。

【讨论】:

    猜你喜欢
    • 2013-12-04
    • 1970-01-01
    • 1970-01-01
    • 2020-03-13
    • 2016-12-11
    • 2015-06-13
    • 2014-02-19
    • 1970-01-01
    • 2021-01-09
    相关资源
    最近更新 更多