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

简介: 之前的一篇博客中提到,物化视图的全量刷新也是一种高可用性的体现,但是性能如何呢,下面来简单的测试一下。 首先需要创建一个函数,这个函数会计算当前session下的一些指标信息。

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

首先需要创建一个函数,这个函数会计算当前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 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量要比普通表多,但是考虑到高可用性的使用,还是不错的选择,毕竟物化视图的优点不在于此,增量刷新和查询重写才是它的亮点所在。

目录
相关文章
|
7月前
|
SQL 关系型数据库 MySQL
实时计算 Flink版产品使用合集之测试使用initial模式,使用savepoint停掉再加上表,不会做全量同步,是什么导致的
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStreamAPI、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
存储 关系型数据库 MySQL
深聊性能测试,从入门到放弃之:性能测试技术栈,看完这篇,保证刷新你对性能测试的认知~~
深聊性能测试,从入门到放弃之:性能测试技术栈,看完这篇,保证刷新你对性能测试的认知~~
203 1
|
7月前
|
存储 前端开发 Oracle
物化视图添加删除列测试
物化视图添加删除列测试
52 2
|
安全 Java 数据库
案例之刷新token测试|学习笔记
快速学习案例之刷新token测试
案例之刷新token测试|学习笔记
|
存储 Cloud Native 多模数据库
阿里云数据库Lindorm刷新TPC物联网测试纪录:性能比第二名高40%
国际处理性能委员会TPC官方披露,在该机构组织的衡量物联网网关系统性能的基准测试中,阿里自研云原生多模数据库Lindorm性能指标创下新纪录,达到485万IoTps,比第二名高出40%,同时成本降低60%以上。
3595 0
阿里云数据库Lindorm刷新TPC物联网测试纪录:性能比第二名高40%
|
计算机视觉
Qt实用技巧:测试80*1080p拼接后显示刷新帧率
Qt实用技巧:测试80*1080p拼接后显示刷新帧率
|
SQL 测试技术 数据库
SQL注入测试平台 SQLol -3.INSERT注入测试
  访问首页的insert模块,http://127.0.0.1/sql/insert.php,开始对insert模块进行测试。 insert语句: INSERT INTO 【users】 (【username】, isadmin) VALUES (【'1'】, 【0】) 接收的参数可能拼接到上述语句中【】的任一个位置。
1264 0
|
测试技术 数据库 SQL
Insert into select 与create table as的性能测试及create table
1. 文档说明 在工作中经常用insert into select 与 create table as语句来进行表单数据的复制;当复制表的数据量很小的时候两个语句的效率区别不大,但当表的数量级别达百万级以上的时候,就会有很明显的效率区别; 本文档也也分...
1433 0
|
27天前
|
JSON Java 测试技术
SpringCloud2023实战之接口服务测试工具SpringBootTest
SpringBootTest同时集成了JUnit Jupiter、AssertJ、Hamcrest测试辅助库,使得更容易编写但愿测试代码。
55 3