【问题标题】:Oracle - What happens when refreshing a 'REFRESH FORCE ON DEMAND' view with DBMS_MVIEW.REFRESHOracle - 使用 DBMS_MVIEW.REFRESH 刷新“REFRESH FORCE ON DEMAND”视图时会发生什么
【发布时间】:2011-09-15 00:15:05
【问题描述】:

我有以下物化视图 -

CREATE MATERIALIZED VIEW TESTRESULT 
ON PREBUILT TABLE WITH REDUCED PRECISION
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
AS 
SELECT...
FROM...
WHERE...

此物化视图没有支持 MATERIALIZED VIEW LOG。从上面的子句中可以看出,这个 MV 有“ON DEMAND”指定,并且根据 Oracle 文档,

"[ON DEMAND] 表示 [s] 视图将根据需要刷新 调用三个 DBMS_MVIEW 之一 刷新程序。”

当我调用 DBMS_MVIEW.REFRESH('TESTRESULT') 时,发生了什么?是否手动检查每条记录是否已更新?

Oracle 版本:10g

【问题讨论】:

    标签: oracle oracle10g materialized-views


    【解决方案1】:

    默认情况下(并且此默认更改在不同版本的 Oracle 中),这将对物化视图进行完整的原子刷新。这意味着物化视图中的数据将被删除,底层查询将被重新执行,结果将被加载到物化视图中。您可以通过为 ATOMIC_REFRESH 参数传入 FALSE 值来提高刷新效率,即

    dbms_mview.refresh( 'TESTRESULT', atomic_refresh => false );
    

    这将导致物化视图被截断,查询重新执行,结果通过直接路径插入插入到物化视图中。这将比原子刷新更有效,但在刷新期间物化视图将是空的。

    【讨论】:

    • +1 @Justin.. 另外,如果我使用 NOLOGGING 创建了 MVIEW,会发生什么?我创建的 MVIEW 总是在 UNDOTBS 小问题上出错。ATOMIC_REFRESH 有帮助吗?
    • @guru - 如果我理解正确,您会收到 ORA-01555 错误,对吧?这意味着问题在于您正在查询的表正在更改,并且您的刷新无法生成刷新开始时存在的数据的一致视图。通常,这意味着UNDO_RETENTION 参数和/或UNDO 表空间太小,应该增加。潜在地,您还可以寻求减少 ATOMIC_REFRESH 将完成的刷新所需的时间。
    • 我的办公室 PC 不在身边,我需要等待获得确切的 ORA 错误。搜索时,Tom Kyte 也提到了 01555。但这就是我所做的。我基于一个大表创建了一个 MVIEW。大约需要40-60分钟。 MVIEW 大小为 35-40 GB。当我使用 DBMS_MVIEW 刷新(完成)它时,脚本会运行 2-3 小时,并且由于 MVIEW REFRESH PATH 大小是一个问题而出错。
    猜你喜欢
    • 2012-08-29
    • 2010-12-10
    • 2014-07-18
    • 2018-04-20
    • 1970-01-01
    • 2018-10-24
    • 2013-09-08
    • 1970-01-01
    • 2013-07-23
    相关资源
    最近更新 更多