基于非快刷新视图的快刷新物化视图
我发现我可以拥有两个表，并根据这些连接的表创建提交时快速刷新 物化视图。
然而，我想做的是基于以下内容进行提交时快速刷新物化视图：
（1）连接到的表
(2) 一个完全按需刷新物化视图，它本身是基于其他视图（即普通视图）的。
当我尝试这样做时，我收到错误 ORA-12053，该错误谈到 from 子句中的条目相互依赖，即使它们显然不存在依赖关系。
我可以通过将 (2) 替换为普通表来解决此问题，并且只需向该表中执行批量插入，而不是刷新物化视图。但是，如果没有必要，我宁愿不这样做。
我将尝试使用一个最小的示例来说明该错误，但是如果您能让我了解我想要做的事情是否可能（最好通过示例）或不可能，那就太好了。
I've found that I can have two tables and create a fast refresh on commit materialized view based on those tables joined.
What I would like to do however is to make a fast refresh on commit materialized view based on the following:
(1) A table JOINED TO
(2) A complete refresh on demand materialized view which itself is based on other views (ordinary views, that is).
When I try to this I get error ORA-12053, which talked about entries in the from clause having dependencies on each other, even when they clearly don't.
I can work around this by replacing (2) with an ordinary table, and just doing a bulk insert into this table instead of refreshing the materialized view. However, I'd rather not do this if not necessary.
I'll try to work on a minimal example that illustrates the error, but if you could give me an idea of whether what I want to do is possible (preferably by an example) or not possible that would be great.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请遵循以下事实来了解错误。
Fast Refresh on Commit物化视图按行刷新基于对基表所做的更改的行。
Refresh Complete on Demand物化视图的刷新方式为截断目标表并重新插入所有内容。
oracle 无法跟踪表 2 上的更改（即刷新完成
物化视图。）
Follow these facts to understand the error.
Fast Refresh on Commitmaterialized view is refreshed row byrow based on changes made on base tables.
Refresh Complete on Demandmaterialized view is refreshed bytruncate the destination table and reinsert everything.
oracle can't track changes on table 2 (that is, the refresh complete
materialized view.)
嵌套物化视图存在限制。我在这篇博文中描述了它们。 ORA-12053 是不满足嵌套 MV 的第一个限制的结果。使底层 MV 更加复杂（连接、聚合或联合所有 MV）是一个解决方案。
问候，
抢。
There are restrictions on nested materialized views. I described them in this blogpost. The ORA-12053 is the result of not satisfying the first restriction of nested MV's. Making the underlying MV more complex (a join, aggregate or union all MV), is a solution.
Regards,
Rob.