Real-time materialized view,面向开发者的12.2新特性

题记:在12.2之前,如果使用on command刷新物化视图,必须得有个job来定时的刷,那么,在一次job运行之后,下一次job到来之前,如果基表有数据变化,那么此时的数据肯定不是最新的。12.2中提出的real time mv即可以帮你获取实时的数据,且不用频繁的刷新mv。

为什么要有real time mv?

在12.2之前,如果你想获得实时的数据,那么在利用query rewrite前,你必须得用on commit的刷新方式刷新物化视图。但是on commit的刷新方式有众多限制,如sql的复杂度,如频繁对系统的压力等等。所以,我们不得不采用on command的方式来进行刷新(不管是全量刷新还是增量刷新)。那么在使用on command刷新的时候,必须得有个job来定时的刷,那么,在一次job运行之后,下一次job到来之前,如果基表有数据变化,那么此时的数据肯定不是最新的。

real time mv就是为了解决这个问题而生的。它即可以帮你获取实时的数据,且不用频繁的刷新mv。我们来看一下这是怎么实现的。

传统mv的创建方式:

Real time mv的创建方式

注意在create mv时的关键字:enable on query computation

我们来比较一下传统mv和real time mv的差别: 相关参数:

初始状态: 传统mv:

Real time mv:

看到此时2个物化视图,数据都是最新的,staleness显示是fresh:

物化视图日志里面也没有记录

我们对基表insert数据:

可以看到2个表的staleness已经变成need compile,且物化视图日志表里面,也与了日志的记录:

我们来见证一下奇迹的时刻。我们先重复上面第一个查询,可以看到,由于数据stale,且没有set query_rewrite_integrity=stale_tolerated,传统mv没有进行query write。

我们看到,real time mv,进行了query rewrite,且查到的数据是最新实时数据!

执行计划如下:

统计信息如下:

我们看到,在查t2的时候,优化器会根据成本决定是否使用query rewrite。 我们的这个例子中CBO选择使用query rewrite。可以看到query rewrite到物化视图之后,不是取的是过期的物化视图的值,而是最新的值。结合执行计划,可以看到,是结合了stale的物化视图,再union all和hash join outer了物化视图日志。得到了最新的结果。

可以看到,使用的物化视图日志是”MAS$”.”SNAPTIME$$”>TO_DATE(‘ 2017-07-12 14:35:01’, ‘syyyy-mm-dd hh24:mi:ss’)之后的。

对比直接从table取值,到利用real time物化视图取值,consistent get从4167变成了1232。注意我们的mv log还是没有被刷新的。还是需要去定期的job刷新:

另外再提一下,有个/*+ fresh_mv */的hint,可以直接查询real time mv的实时结果:

综上,Real time mv利用原来的已经stale的物化视图,结合mv log,通过计算后,帮你获取实时的数据。你即能获得实时数据,又不必那么频繁的刷新mv。

参考: https://blogs.oracle.com/sql/12-things-developers-will-love-about-oracle-database-12c-release-2#real-time-mv https://blog.dbi-services.com/12cr2-real-time-materialized-view-on-query-computation/ https://uhesse.com/2017/01/05/real-time-materialized-views-in-oracle-12c/ https://docs.oracle.com/database/122/SQLRF/CREATE-MATERIALIZED-VIEW.htm#SQLRF01302

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-07-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏沃趣科技

初相识 | 全方位认识 sys 系统库

前阵子,我们的"全方位认识performance_schema"系列为大家完整的介绍了performance_schema系统库。在我们的发布计划中为什么要把p...

1883
来自专栏CSDN技术头条

应当使用 SQLite 的五个原因

SQLite 是非常优秀的数据库,能够在真实的生产环境中完成一些真正的工作。本文将列出五个我认为在2016年应当选用 SQLite 的原因。 ? 便于管理 不知...

2248
来自专栏杨建荣的学习笔记

海量数据迁移之传输表空间(一) (r5笔记第71天)

在自己接触的很多的数据迁移工作中,使用外部表在一定程度上达到了系统的预期,对于增量,批量的数据迁移效果还是不错的,但是也不能停步不前,在很多限定的场景中,有很多...

2317
来自专栏idba

死锁案例之十

死锁,其实是一个很有意思也很有挑战的技术问题,大概每个DBA和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析,希望能够对想了解死锁的朋...

962
来自专栏MySQL实战分享

【MySQL经典案例分析】 Waiting for table metadata lock

2018年某个周末,接到连续数据库的告警,看到too many connection的报错信息,基本上可以把问题定位在...

4806
来自专栏杨建荣的学习笔记

一则orabbix报警的分析(r6笔记第65天)

最近使用zabbix监控之后,都会在凌晨收到1台数据库服务器的报警短信,报警的内容为: No data received from Orabbix 这个错误其实...

3038

使用 Excel 分析 CloudStack 使用记录

注:本文最初由 David Nailey 在 Build a Cloud 博客上撰写。

2059
来自专栏数据和云

故障分析:一则library cache lock问题处理

编辑手记:library cache lock 大家都并不陌生,在MOS上对该阻塞的一般成因描述为:一般可以理解的是alter table或者alter pac...

3595
来自专栏数据和云

细致入微:Oracle中执行计划在Shared Pool中的存储位置探秘

这两天我一直在想一个问题,那就是 Oracle 的执行计划到底存储在什么地儿?它会是一种什么样的格式? 这里我试图对这个问题做一点我自己认为的解释,这个解释可能...

2935
来自专栏思考的代码世界

Python网络数据采集之存储数据|第04天

存储媒体文件有两种主要的方式:只获取文件 URL 链接,或者直接把源文件下载下来。

4387

扫码关注云+社区