问题描述
你好,
我正在调查长时间的物化视图快速刷新。我创建了实时sql测试用例,它模拟了我的情况,但在较小的数据集上。
从我的观察刷新期间最长的运行查询是:
和
Comm和used in refresh:
Comm和used to manipulate data:
So all that RDBMS does is counting all rows of MVIEW 和source table at end of refresh which seems unnecessary IMO..
这是意料之中的吗?我能加快速度吗?
P.S. Relation between data1_tab 和data2_tab is many to many. It looks ugly but this is requirement to compare values in such fashion..
致以最诚挚的问候,
格里戈里
<更新>
多亏了橡皮鸭效应,我才想出了解决办法。
It looks like RDBMS is counting rows due to new table DBA_MVREF_STATS. It populates number of rows before 和after refresh.
要跳过此步骤,必须将DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS中的collection_level设置为null值。在那之后,MV以毫秒的时间刷新,不超过几分钟。
感谢您强迫我收集所有信息,这使我得出了这个结论 :)
更新>
我正在调查长时间的物化视图快速刷新。我创建了实时sql测试用例,它模拟了我的情况,但在较小的数据集上。
从我的观察刷新期间最长的运行查询是:
select count (*) from data1j2_tab_mv
和
select count (*) from data1_tab
Comm和used in refresh:
BEGIN dbms_mview.refresh('data1j2_tab_mv', method => 'F',atomic_refresh=>FALSE); END;/Comm和used to manipulate data:
update data1_tab set col1='Y' where fk_key=1 和col1='B';
So all that RDBMS does is counting all rows of MVIEW 和source table at end of refresh which seems unnecessary IMO..
这是意料之中的吗?我能加快速度吗?
P.S. Relation between data1_tab 和data2_tab is many to many. It looks ugly but this is requirement to compare values in such fashion..
致以最诚挚的问候,
格里戈里
<更新>
多亏了橡皮鸭效应,我才想出了解决办法。
It looks like RDBMS is counting rows due to new table DBA_MVREF_STATS. It populates number of rows before 和after refresh.
要跳过此步骤,必须将DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS中的collection_level设置为null值。在那之后,MV以毫秒的时间刷新,不超过几分钟。
感谢您强迫我收集所有信息,这使我得出了这个结论 :)
更新>
专家解答
格里戈里,我向你致敬!
人们很少在发布问题后继续调查问题。然后通知我们他们找到了解决办法。
一个小问题-为了避免统计数据收集,你应该使用级别到无:
使用null应该可以获取系统级默认值。
但仍然,伟大的工作 :)
人们很少在发布问题后继续调查问题。然后通知我们他们找到了解决办法。
一个小问题-为了避免统计数据收集,你应该使用级别到无:
exec dbms_mview_stats.set_mvref_stats_params ( 'data1j2_tab_mv', 'NONE' );
使用null应该可以获取系统级默认值。
但仍然,伟大的工作 :)
文章转载自ASKTOM,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




