Sql 刷新视图的结果时？

我在表中具体化视图的结果。 我想知道他们是否可以知道这个视图的结果何时更改为刷新它。 物化视图和结果缓存可以做到这一点，但我不想同时使用这两种技术。 他们是回答这个问题的另一种方式吗

事实上，我们有一个通用系统，它每n分钟具体化并刷新一次视图。刷新的成本可能很高，我试图知道我们是否可以知道底层数据是否发生了更改

我们不使用物化视图，因为完全刷新会截断表，而快速刷新只在主键为的表上工作

结果缓存无法对执行此任务，因为我们没有足够的内存

---

因此，我想知道我们是否可以使用一种技术来了解自上次刷新以来视图的基础数据是否发生了更改

您可以有一个如下所示的标志表：

CREATE TABLE FlagTable
  SourceTable varchar(30),
  UpdateDate DATETIME,
  Handled CHAR(1) DEFAULT 'N'

在基表上创建触发器，在插入、更新或删除表时，将一条记录插入到带有基表名称的FlagTable中

---

当您想要检查刷新时，只需选择WHERE Handled='N'，刷新伪视图，然后设置Handled='Y'

这只是一种启发式方法，但作为视图刷新过程的一部分，您可以查询并存储源表中的max

或u rowscn

和行数。然后定期检查这些值，以查看这些表中的某些表是否已更改

select MAX(ora_rowscn), COUNT(*) 
  into last_change_scn, last_change_length 
  from src_table;

如果我没说错的话，如果您的表中有任何插入或更新，

MAX（ora_rowscn）

将发生更改。如果有一些删除，

COUNT（*）

会改变

---

在黑暗面，查询

MAX（ora_rowscn）

将触发全表扫描。当然，这并不能告诉您这些更改是否会影响视图。

您可以用一种更简单的方法来完成这一切，方法是将mat_视图设置为提交时刷新选项，如果可能，还可以使其提交时快速刷新。这将保证每次发生更改时，视图只刷新新行（与完全刷新相比，视图后面的查询作为一个整体执行）

现在，最后一种方法可能会导致很多问题，因为提交时快速刷新选项有局限性，如果您不能遵守它，就不能使用它。但是，如果您可以将其设置为“提交时刷新完成”，这可能会降低系统的运行速度（正如您建议的那样），也可能表明您无法隔离更改的来源

如果您想查看最频繁的更改发生在何处，我建议您使用一个自定义表（每天），将每日查询结果存储在mat_视图后面。然后几天后，做一些类似的事情：

select * from daily_table_day_one
minus
select * from mat_view
union all
select * from mat_view
minus
select * from daily_table_day_one

因为使用

ORA_ROWSCN

的方法并不总是有效的。带有触发器的方法在有限的情况下工作，如果不需要在100个表上创建这些触发器。。。那太可笑了

当您找到更改的来源——例如几个列，来自一些表时，您可能会考虑重写MaTeVIEW查询，遵循一些DW原则并创建查询的星形架构。这将对查询进行分段，并肯定会加快查询速度。检查负载来自何处-如果这些昂贵的连接、扫描无法避免，那么在较小的查询上分解查询可能会奏效，如果您也可以具体化它们，也许您还可以使用提交时快速刷新来设置它们

这完全取决于实施情况。如果您可以在这里给出一个查询示例或查询的一部分，通过解释计划，我们还可以为您提供具体的解决方案

---

干杯

你能发布你的观点吗？你的意思是你根本不想使用物化视图吗？或者只是与结果缓存一起使用？如果您想推出自己的原始解决方案（不确定为什么，但如果数据库内置了支持），您可以在视图基于的表上使用后插入触发器更新表，我们假设该表没有主键？您好。你是对的。表没有主键。您好g00dy，感谢您的解释。很清楚。不幸的是，这与我的问题不符。我们有一个非常通用的系统，有时具有快速刷新的mat视图可以解决我们的问题，有时则不能。每个功能用户都可以在我们的系统中要求一个新的视图，而我们无法控制它们。这就是为什么我们不能使用物化视图来解决它。