当前位置:首页 > 数据库 > Oracle技术

oracle multilized view fast refresh 为何反而比 complete refresh 还要慢,有什么解决策吗

优良自学吧提供oracle multilized view fast refresh 为何反而比 complete refresh 还要慢,有什么解决策吗,oracle multilized view fast refresh 为什么反而比 complete refresh 还要慢,有什么解决策吗背景:某表部署了Mview refresh频率:10分钟 目标数据量:130万件 方案1:如果采用fast&n

oracle multilized view fast refresh 为什么反而比 complete refresh 还要慢,有什么解决策吗
背景:某表部署了Mview
refresh频率:10分钟
目标数据量:130万件

方案1:如果采用fast refresh方式,差异部分的delete实行时间是70秒左右,差异部分的insert实行时间在760秒左右,合计15分钟左右
方案2:如果采用complete refresh方式,全量的delete实行时间是59秒左右,全量的insert实行时间在55秒左右,合计2分钟左右
方案3:如果采用complete refresh方式,全量的truncate实行时间是12秒左右,全量的insert实行时间在55秒左右,合计1分钟左右

由于truncate的complete refresh导致12秒检索不出来数据(和insert不是一个transaction),方案3被否决了.

方案1 和 方案2 的结果差别太大,原因如下:
第一:由于fast refresh发生了全表扫描,差分的比较更加花费时间
第二:Mview的基表数据量过大,导致insert的时候执行的select无法适用index

另外,如果采用方案1,发生了UNDO表领域枯竭的现象

现在采用方案2的方式在运行,运行一年后,即使方案2的refresh也变慢,原因是基表数据的海量增长.10分钟之内refresh变的比较危险

鉴于以上现象,在不增加硬件设备的前提下,高手们有什么好的方案吗?
方案1或者方案2都可以,实现目标,控制refresh的时间
另外,采用方案1,发生了UNDO表领域枯竭的现象 也想请假下原因

------解决思路----------------------
1、首先,感觉库的性能不太好,具体刷新慢的原因,没看到具体的物化定义,也不了解数据环境,不太好确定;
2、方案一发生undo空间枯竭,估计是你看到了什么报错,原因很可能是,物化定义中的sql查询语句运行时间过长,导致undo需保存的数据过多导致的。

(本文来自互联网,不代表搜站(http://www.ylzx8.cn/)的观点和立场)
本站所有内容来自互联网,若本站收录的信息无意侵犯了贵司版权,请给我们来信(ylzx8cn@163.com),我们会及时处理和回复,谢谢