物化视图全量刷新与insert的redo生成量测试(69天)

之前的一篇博客中提到,物化视图的全量刷新也是一种高可用性的体现,但是性能如何呢,下面来简单的测试一下。

首先需要创建一个函数,这个函数会计算当前session下的一些指标信息。比如redo的生成量。

  CREATE OR REPLACE FUNCTION "GET_STAT_VAL" (p_name in varchar2) 
   return number 
as 
l_val number; 
begin 
select b.value into l_val from v$statname a,v$mystat b 
where a.statistic#=b.statistic# 
and a.name=p_name; 
return l_val; 
end;
/

然后创建一个shell脚本test.sh,这样就可以直接来运行sql语句,马上得到结果了。脚本内容如下:

sqlplus -s xxx/xxxx <<EOF 
set echo on 
set feedback off 
variable redo number 
exec :redo :=get_stat_val('redo size'); 
prompt start to gather redo size ... 
set serveroutput on 
set timing on 
alter system flush buffer_cache; 
$1 
--prompt finished gather redo size ... 
set timing off 
exec dbms_output.put_line((get_stat_val('redo size')-:redo)||' bytes of redo generated...'); 
EOF 
exit

首先来创建基表

SQL> create table tab_test tablespace pool_data as select *from dba_objects;
Table created.
SQL> select bytes from dba_segments where segment_name='TAB_TEST';
     BYTES 
---------- 
   2097152

然后使用Insert into tab_test select *from tab_test;然数据自增。达到24M左右的样子。

SQL> select bytes from user_segments where segment_name='TAB_TEST';
     BYTES 
---------- 
 24117248
SQL> commit;
Commit complete.

创建物化视图,默认使用全量刷新,可以看到生成的redo和物理段的大小基本一致。

$ ksh test.sh "create materialized view mv_test as select *from tab_test;" 
start to gather redo size ... 
Elapsed: 00:00:00.11 
Elapsed: 00:00:02.87 
23327504 bytes of redo generated...

然后创始全量刷新,发现redo量有了极大的增长,一下子达到了100多M. 响应时间从2秒一下子涨到了13秒。

$  ksh test.sh "exec dbms_mview.refresh('MV_TEST','C'); " 
start to gather redo size ... 
Elapsed: 00:00:00.83 
Elapsed: 00:00:13.36 
102212976 bytes of redo generated...

是不是所有的场景下全量刷新都会这么慢呢,看下面的例子。先truncate掉,然后再次全量刷新。发现响应时间一下子又恢复了2秒的样子。

$ ksh test.sh "truncate table mv_test;" 
start to gather redo size ... 
Elapsed: 00:00:25.13 
Elapsed: 00:00:00.17 
65220 bytes of redo generated...
$ ksh test.sh "exec dbms_mview.refresh('MV_TEST','C');" 
start to gather redo size ... 
Elapsed: 00:00:15.02 
Elapsed: 00:00:01.65 
23112468 bytes of redo generated...

如果已经刷新过,再次刷新,redo量又开始达到100M左右,我感觉物化视图刷新的过程中,对已有数据的刷新,又要删除原有数据,又要保证数据的读一致性,可能在实现上性能不够理想。

$ ksh test.sh "exec dbms_mview.refresh('MV_TEST','C');" 
start to gather redo size ... 
Elapsed: 00:00:14.86 
Elapsed: 00:00:11.13 
102370296 bytes of redo generated... 
$

下面来看看普通表的Insert性能相比物化视图刷新的情况,创建表insert_test。

首先来测试一下表在nologging的时候redo的情况,可以看到redo生成量只有118k左右。

create with nologging 
$ ksh test.sh "create table insert_Test tablespace pool_data nologging as select *from tab_test;" 
start to gather redo size ... 
Elapsed: 00:00:23.48 
Elapsed: 00:00:02.88 
117892 bytes of redo generated...

毕竟nologging使用的场景有限,在没有确认备份和业务需要的时候,不建议这么做。来看看默认使用Logging的时候。redo生成量和物理段基本一致。

create with logging 
$ ksh test.sh "create table insert_test tablespace pool_data as select *from tab_test;"          
start to gather redo size ... 
Elapsed: 00:00:00.08 
Elapsed: 00:00:01.96 
23291008 bytes of redo generated...

然后尝试truncate以后,使用insert插入数据。

$ ksh test.sh "truncate table insert_test;" 
start to gather redo size ... 
Elapsed: 00:00:00.06 
Elapsed: 00:00:00.16 
62956 bytes of redo generated...

如果使用insert append的方式插入,测试的这个库在archive的模式下,可以看到性能没有什么变化。

$ ksh test.sh "insert into /*+append */ insert_test select *from  tab_test;" 
start to gather redo size ... 
Elapsed: 00:00:03.15 
Elapsed: 00:00:01.60 
23085680 bytes of redo generated...

使用常规的insert的时候,redo生成量也没有明显的变化。

ksh a.sh "insert into insert_test select *from tab_test;" 
start to gather redo size ... 
Elapsed: 00:00:00.09 
Elapsed: 00:00:01.34 
23078764 bytes of redo generated...

这么看materialized view和insert的性能没有明显的差别。

可以考虑使用parallel让性能提升一个层次。

首先设置object级别的parallel

$ ksh a.sh " alter table insert_test parallel 2;" 
start to gather redo size ... 
Elapsed: 00:00:00.06 
Elapsed: 00:00:00.08 
2224 bytes of redo generated...

然后开启session级别的parallel,就是在test.sh里面加入一句

alter session enable parallel dml;

然后执行,可以看到redo的生成量才18K的样子,性能确实有了很大的提升。

ksh a.sh "insert into insert_test select *from tab_test;" 
start to gather redo size ... 
Elapsed: 00:00:00.10 
Elapsed: 00:00:00.01 
Elapsed: 00:00:04.19 
17908 bytes of redo generated...

看到并行的效果这么明显,难道物化视图刷新就没有并行吗,可以的,不过性能也确实没有什么提升,不知道自己设置的参数不够合理还是本来物化视图的实现细节复杂。

ksh a.sh "exec dbms_mview.refresh('MV_TEST','C',PARALLELISM=>2);" 
start to gather redo size ... 
Elapsed: 00:00:24.23 
Elapsed: 00:00:11.30 
102474472 bytes of redo generated...

由上可以看到,物化视图的刷新在性能和灵活性上没有普通表那么灵活。生成的Redo量要比普通表多,但是考虑到高可用性的使用,还是不错的选择,毕竟物化视图的优点不在于此,增量刷新和查询重写才是它的亮点所在。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-05-11

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术分享

.NET应用架构设计—面向查询服务的参数化查询设计(分解业务点,单独配置各自的数据查询契约)

阅读目录: 1.背景介绍 2.对业务功能点进行逻辑划分(如:A、B、C分别三个业务点) 2.1.配置映射关系,对业务点配置查询契约(构造VS插件方便生成查询契...

2018
来自专栏数据和云

微信课堂:化解控制文件归档日志查询缓慢及ASM执行计划一则

在我们的技术讨论群『云和恩墨大讲堂』中,还有日常的微信互动中,经常有朋友会提出一些有趣的小问题,在空闲的时候,我希望能够记录下来,和大家做一点小分享,以点滴的知...

904
来自专栏数据和云

DBA入门之路:察微知渐细致入微

在DBA的职业生涯中,要面临无数的艰难险阻、排忧解难,所以细致入微,严谨认真的风格必不可少。养成了察微知渐的习惯,才能在分析诊断故障时层剖缕析,直指核心;而我也...

2033
来自专栏极客生活

python爬虫隔一段时间一乐之海子的诗

每隔一段时间(一周到一个月)拿出1到2天来做一个好玩的东西,不求回报,只为快感。 前两天刚买了一本电子书《海子的诗》,晚上读了快一半,好多诗里面都提及了麦子和...

671
来自专栏GreenLeaves

数据库事务的一致性和原子性浅析

本文参考自知乎 Oracle事务的概念:事务用户保证数据的一致性,它是由一组dml语句组成,这组dml语句要么全部执行成功,要么全部执行失败。 1、事务一致性 ...

1786
来自专栏Linyb极客之路

Spring Boot最佳实践

782
来自专栏企鹅号快讯

Java框架之spring—jdbcTemplate第二节

Java框架之spring—jdbcTemplate 小伙伴们还记得 Spring IOC 的注解注入方式吗? 今天就来把上次写的 jdbcTemplate 转...

34410
来自专栏岑玉海

RavenDb学习(一)设计模式介绍

RavenDb是一个文档型的数据库,和芒果Db是一个类型的东西,但是公司选择了它,主要是因为它对事务的支持比较好,芒果Db在事务方面有问题。 下面有一个例子...

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

备库CPU使用异常优化(r6笔记第73天)

一般在一些容灾环境中,尤其是在11g的ADG非常普及的场景下,备库被赋予了更多的责任,很多时候在容忍一些延迟的情况下,有些应用的大量数据查询任务直接放到了备库,...

2784
来自专栏逸鹏说道

我为NET狂官方面试题-数据库篇答案

说明:如有错误可以批评指正,有更好写法也可以提点下~ 1. 求结果:select "1"? 报错,SQL里面只有单引号,列如:'xx' 2. 查找包含"obj...

3378

扫码关注云+社区