我有MY_VIEW_A
这是MY_VIEW_B
和MY_MATERIALIZED_VIEW_C
的联盟。
MY_VIEW_B
的约束为MY_DATE > (SYSDATE - 1) + 1 / 24
。
MY_MATERIALIZED_VIEW_C
由间隔为TRUNC(SYSDATE+1) + 1/24
的作业更新。请注意,这可能无效......我正在处理的问题是作业停止运行。也许是由于10G 11G迁移。
我很想知道1/24
在这些情况下意味着什么。从四处看看,我相信这表明1小时。那么我认为以下可能是正在发生的事情。
MY_VIEW_B
仅检索过去23小时内MY_DATE
的实体。MY_MATERIALIZE_VIEW_C
每25小时更新一次。然而,这似乎是一个有问题的情况。作为24小时前制作的实体,可能不在任何一种观点中。
我不明白吗?或者设置确实有问题吗?
答案 0 :(得分:3)
1/24
确实可以转换为1小时。就个人而言,我更喜欢使用区间符号而不是添加和删除分数天。
SYSDATE - interval '23' hour
对我来说似乎更具可读性。
您的物化视图每24小时更新一次。它将每天凌晨1点更新。
TRUNC(SYSDATE+1) + 1/24
明天凌晨1点返回。 trunc(sysdate)
今天是午夜,trunc(sysdate+1)
明天是午夜,trunc(sysdate+1) + 1/24
明天凌晨1点。
如果您在午夜和物化视图完成刷新之前查询视图(可能是在凌晨1点之后的某个时间),则可能存在超过23小时的行尚未在物化视图中反映的行。根据架构(以及条目显然存在于两个不同对象中的原因),我会更关注重复行。例如,早上8点,物化视图的数据只有7个小时(大概),也可以从my_view_b
返回(我假设当你说“约束”时你真的意味着有一个my_view_b
上的谓词,如WHERE MY_DATE > (SYSDATE - 1) + 1 / 24
)。
UNION
以删除重复项似乎对我非常怀疑。如果您使用物化视图预先聚合数据或至少预先计算在运行时计算成本高昂的东西,那么物化视图通常会提高性能。但是,这似乎并不是你正在使用它们的原因,所以我非常怀疑除了让你使用更多的磁盘空间,给缓冲区缓存施加更大的压力,以及性能更差外