我最近注意到调用dbms_mview.refresh(...)来刷新Oracle中的物化视图,它有一个隐式提交.

任何想法 - 除了"因为它确实" - 为什么这个动作有一个隐含的提交？

我在Oracle 11g中有一个表demo_fact,它有几个虚拟列定义如下:

ALTER TABLE demo_fact ADD (demo_measure_from_virtual NUMBER GENERATED ALWAYS AS
  (CASE WHEN  demo_category_column = 20 THEN demo_numericdata_column ELSE 0 END)
  VIRTUAL VISIBLE);

然后我将物化视图定义为

CREATE MATERIALIZED VIEW demo_agg_mv 
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE
AS 
SELECT
  demo_dim_one,
  demo_dim_two,
  SUM(demo_measure_from_virtual) demo_measure_from_virtual
  FROM demo_fact
  GROUP BY demo_dim_one, demo_dim_two

现在我想要Query Rewrite来启用以下查询:

SELECT demo_dim_one, SUM(demo_measure_from_virtual) 
FROM demo_fact
GROUP BY demo_dim_one

但事实并非如此.我运行了EXPLAIN_REWRITE,这是输出:

QSM-01150: query did not rewrite
QSM-01102: materialized view, DEMO_AGG_MV, requires join back to table, 
           DEMO_FACT, on column, DEMO_MEASURE_FROM_VIRTUAL
QSM-01082: Joining materialized view, …

假设我有一个表TABLE有两列COL_1和COL_2.

我有一个简单的读取的物化视图TABLE.COL_1,并设置为:REFRESH FAST ON COMMIT.

如果我更新TABLE.COL_2,物化视图是否刷新？

我使用基本物化视图和按需快速刷新功能从我们的OLTP Oracle数据库中掌握了一个数据集市.刷新工作正常.我有兴趣添加的是有关每个物化视图刷新的一些统计信息,例如自上次刷新以来应用于主表的插入,更新和删除的数量,就像我可以找到的数据一样user_tab_modifications.物化视图有可能吗？

我有一个物化视图,我想在使用快速刷新的提交(来自按需)上改变.

但是我不断得到

ora-32337 cannot alter materialized view with pending changes refresh on commit

甚至在刷新之后直接(并且知道没有进行任何更改).

可能是什么原因造成的？MV使用外连接,这可能是个问题吗？(MV日志适用于所有表格)

我有一个物化视图,我需要重新定义SQL.我们有一个外部系统可以通过db链接查看视图,并且怪物视图需要5分钟来刷新视图中的数据.我知道如何为视图重新定义SQL的唯一方法是删除它并重新创建它,但如果外部系统找不到表,或者它没有完整的数据集,那将是非常糟糕的.我需要尽可能少的停机时间.

有没有办法在本地或更优雅地执行此操作:

1. 为物化视图创建公共同义词,并使使用该视图的所有内容都使用同义词.
2. 使用新SQL创建新的物化视图
3. 将同义词更改为指向新视图
4. 放弃旧观点.

我有动态执行此操作的代码,但它变得非常难看.似乎应该有更好的方法来处理这个问题.

我们有一个表TB_1,其中包含按月和每周列分区的每月和每周数据.我们还有MV_1从表继承的物化视图TB_1.

我们希望每周或每月刷新物化视图.

不确定我们如何从物化日志中捕获的所有更改中过滤每周或每月更改以进行部分刷新.

现在我们正在考虑在其中设置一个标志列TB_1.通过清除物化日志并更新标志,我们认为我们可以实现这一目标.

无论如何有效的方式比特定标准的部分刷新过程？

在PostgreSQL 9.5中，我决定创建一个物化视图“效果”，并计划每小时进行一次并发刷新，因为我希望它始终可用：

REFRESH MATERIALIZED VIEW CONCURRENTLY effects;

在开始的时候，一切都运行良好，我的实例化视图令人耳目一新，磁盘空间使用大致保持不变。

问题

但是，一段时间后，磁盘使用率开始线性增长。

我已经得出结论，这种增长的原因是物化视图，并从该答案中运行查询以得到以下结果：

               what                |  bytes/ct   | bytes_pretty | bytes_per_row
-----------------------------------+-------------+--------------+---------------
 core_relation_size                | 32224567296 | 30 GB        |         21140
 visibility_map                    |      991232 | 968 kB       |             0
 free_space_map                    |     7938048 | 7752 kB      |             5
 table_size_incl_toast             | 32233504768 | 30 GB        |         21146
 indexes_size                      | 22975922176 | 21 GB        |         15073
 total_size_incl_toast_and_indexes | 55209426944 | 51 GB        |         36220
 live_rows_in_text_representation  |   316152215 | 302 MB       |           207
 ------------------------------ …

我创建了一些物化视图，Oracle SQL Developer 在每个视图旁边放了一个红色的小“x”。目前，当我查询它们并在 SQL Plus 中运行以下查询时，它们返回正确的信息表明没有错误：

SELECT * FROM USER_SNAPSHOTS

ERROR对于有问题的物化视图，此列中的列返回 0。

有谁知道为什么 SQL Developer 认为有错误？我还有其他地方可以检查吗？

更新

根据帕特里克的建议，我运行了以下查询：

SELECT * FROM ALL_MVIEWS

对于每个有问题的视图，COMPILE_STATE 是“NEEDS_COMPILE”。这是什么意思？为什么需要重新编译？未更改任何基础表。

我们有一个高度（也许已经结束？）规范化的表来跟踪版本化的值。它只是插入，没有更新。

示例数据：

"ID"    "Version"   "Value"
1       0           "A_1"
2       0           "B_1"
1       1           "A_2"
3       0           "C_1"

我们经常运行查询以仅提取每个 ID 的最新值。当我们处理数百万行时，我们开始遇到性能问题。我已经能够使用物化视图对改进进行原型设计，但无法以它们自刷新“ON COMMIT”的方式创建它们

到目前为止我得到的是这个（修改如下）

CREATE MATERIALIZED VIEW TABLE_LATEST 
    BUILD IMMEDIATE
    REFRESH FAST 
    ON COMMIT AS

SELECT  T.ID
       ,T.LAST_VERSION
FROM (
    SELECT  ID
           ,MAX(VERSION) OVER (PARTITION BY ID) LAST_VERSION
    FROM    TABLE
) T
GROUP BY T.ID, T.LAST_VERSION;

由于反馈，现在对其进行了修订：

CREATE MATERIALIZED VIEW TABLE_LATEST 
    BUILD IMMEDIATE
    REFRESH FAST 
    ON COMMIT AS

SELECT  ID
       ,MAX(VERSION)
FROM    TABLE
GROUP BY T.ID;

哪个失败了：

ORA-12033: 无法在“SCHEMA”.“TABLE”上使用物化视图日志中的过滤器列

*Cause:    The materialized …

Run Code Online (Sandbox Code Playgroud)