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

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

CREATE OR REPLACE FUNCTION "GET_STAT_VAL" (p_name in varchar2)

/

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

sqlplus -s xxx/xxxx <<EOF

首先来创建基表

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

然后使用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;" 23327504 bytes of redo generated...

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

$ ksh test.sh "exec dbms_mview.refresh('MV_TEST','C'); " 00:00:13.36

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

$ ksh test.sh "truncate table mv_test;"

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

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

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

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

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

create with nologging 117892 bytes of redo generated...

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

create with logging 23291008 bytes of redo generated...

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

$ ksh test.sh "truncate table insert_test;"

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

$ ksh test.sh "insert into /*+append */ insert_test select *from tab_test;" 23085680 bytes of redo generated...

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

ksh a.sh "insert into insert_test select *from tab_test;" 23078764 bytes of redo generated...

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

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

首先设置object级别的parallel

$ ksh a.sh " alter table insert_test parallel 2;"

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

alter session enable parallel dml;

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

ksh a.sh "insert into insert_test select *from tab_test;" 17908 bytes of redo generated...

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

ksh a.sh "exec dbms_mview.refresh('MV_TEST','C',PARALLELISM=>2);" 102474472 bytes of redo generated...

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