我在同一个表上使用left JOIN,因为我想将数据从行转移到列.此Oracle版本中不提供pivot命令,并且在FAST REFRESH物化视图上不允许使用GROUP BY CASE.
物化视图日志如下所示:
CREATE MATERIAliZED VIEW LOG ON Programmes_TitlesWITH PRIMARY KEY,rowIDINCLUDING NEW Values;
Materialized VIEw本身看起来像这样(它包含700000行,Programmes_Titles表包含900000行):
CREATE MATERIAliZED VIEW Mv_Web_ProgrammesREFRESH FAST ON COMMIT ASSELECT t1.ProgrammeID,t1.Title as MainTitle,t2.Title as SecondaryTitle,--Primary key t1.Title_ID as t1_TitleID,t2.Title_ID as t2_TitleID,t1.rowID as t1_rowID,t2.rowID as t2_rowIDFROM Programmes_Titles t1,Programmes_Titles t2WHERE t1.Titles_Group_Type = 'mainTitle' AND t1.Programme_ID = t2.Programme_ID(+) AND t2.Titles_Group_Type(+) = 'secondaryTitle'
我使用的UPDATE语句是这样的:
UPDATE Programmes_Titles SET Title = 'New Title' WHERE rowID = 'AAAL4cAAEAAAftTABB'
此UPDATE语句需要17个小时.
使用INNER JOIN(删除()时)需要几毫秒.
我也尝试在Mv_Web_Programmes物化视图上添加INDEXES,但这似乎也没有帮助. (它仍然运行超过一分钟,这是缓慢的方式,我没有等待每次更改后17小时,所以它可能会改善UPDATE)
所以我的问题是:为什么需要这么长的时间来更新基础表?我怎样才能改善这个?
解决方法 我已经设法在10.2.0.3实例上重现您的问题.自连接和外连接似乎是主要问题(尽管在MV的每一列上都有索引,它最终会在一分钟内更新).起初我以为你可以使用聚合MV:
sql> CREATE MATERIAliZED VIEW LOG ON Programmes_Titles 2 WITH PRIMARY KEY,ROWID (programmeID,Titles_Group_Type,Title) 3 INCLUDING NEW Values;Materialized vIEw log createdsql> CREATE MATERIAliZED VIEW Mv_Web_Programmes 2 REFRESH FAST ON COMMIT 3 AS 4 SELECT ProgrammeID,5 MAX(decode(t1.Titles_Group_Type,'mainTitle',t1.Title)) MainTl,6 MAX(decode(t1.Titles_Group_Type,'secondaryTitle',t1.Title)) SecTl 7 FROM Programmes_Titles t1 8 GROUP BY ProgrammeID;Materialized vIEw created
不幸的是,正如你所注意到的那样,10g a MV that contains MIN or MAX can only be fast-refreshed on commit after insert(所谓的仅插入MV).上述解决方案不适用于更新/删除(MV必须手动刷新).
您可以跟踪会话并打开跟踪文件以查看执行的SQL查询,以便您可以找到是否可以通过索引对其进行优化.
总结以上是内存溢出为你收集整理的Oracle – FAST REFRESH使用LEFT JOINS更新的物化视图非常慢全部内容,希望文章能够帮你解决Oracle – FAST REFRESH使用LEFT JOINS更新的物化视图非常慢所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)