[20150629]物化视图刷新atomic_refresh.txt

[20150629]物化视图刷新atomic_refresh.txt

--11G物化视图刷新有1个参数atomic_refresh.
--如果为false,采用的方式是truncate,再使用/*+ append */ 提示insert。这样redo最少,但是刷新期间无法访问。
--如果为true,采用的方式是delete,再insert。这样产生许多redo与undo。这样在刷新期间访问没问题,最多有点慢。
--自己做一个测试:

1.建立测试环境:
SCOTT@test> @ver1

PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.3.0     Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

create table t as select * from all_objects a;
create materialized view t_mv build immediate refresh on demand enable query rewrite as
select * from t  ;

insert into t select * from all_objects a where rownum commit;

2.测试atomic_refresh=>false:

SCOTT@test> @viewredo
NAME                                                         STATISTIC#      VALUE
------------------------------------------------------------ ---------- ----------
user commits                                                          6          0
redo size                                                           178       1624
redo wastage                                                        183          0
data blocks consistent reads - undo records applied                 293          0

SCOTT@test> exec dbms_mview.refresh('T_MV','C', atomic_refresh=>false);

PL/SQL procedure successfully completed.

SCOTT@test> @viewredo
NAME                                                         STATISTIC#      VALUE
------------------------------------------------------------ ---------- ----------
user commits                                                          6          8
redo size                                                           178    8945556
redo wastage                                                        183          0
data blocks consistent reads - undo records applied                 293          0

--redo size = 8945556-1624=8943932 (大约9M)

3.测试atomic_refresh=>true:

SCOTT@test> @viewredo
NAME                                                         STATISTIC#      VALUE
------------------------------------------------------------ ---------- ----------
user commits                                                          6          0
redo size                                                           178       1624
redo wastage                                                        183          0
data blocks consistent reads - undo records applied                 293          0

SCOTT@test> exec dbms_mview.refresh('T_MV','C', atomic_refresh=>true);
PL/SQL procedure successfully completed.

SCOTT@test> @viewredo
NAME                                                         STATISTIC#      VALUE
------------------------------------------------------------ ---------- ----------
user commits                                                          6          5
redo size                                                           178   38591500
redo wastage                                                        183          0
data blocks consistent reads - undo records applied                 293          0

--redo size = 38591500-1624=38589876 (38M)

4.做一个10046跟踪看看。

SCOTT@test> @10046on 12
Session altered.

SCOTT@test> exec dbms_mview.refresh('T_MV','C', atomic_refresh=>false);
PL/SQL procedure successfully completed.

SCOTT@test> @10046off
Session altered.

--查看跟踪文件:

SQL ID: 2np117amcrkzv Plan Hash: 1163268061
truncate table "SCOTT"."T_MV" purge snapshot log

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          1           0
Execute      1      0.01       0.55          5          1        248           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.01       0.56          5          1        249           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84     (recursive depth: 1)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Disk file operations I/O                        2        0.00          0.00
  reliable message                                2        0.00          0.00
  enq: RO - fast object reuse                     1        0.50          0.50
  db file sequential read                         5        0.00          0.00
  local write wait                                3        0.01          0.04
********************************************************************************

SQL ID: 5zvka3vvfgdvb Plan Hash: 570131543

INSERT /*+ BYPASS_RECURSIVE_CHECK APPEND  */ INTO "SCOTT"."T_MV" select *
  from t

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          1          0           0
Execute      1      0.34       0.54          2       1162       1719       75118
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.34       0.54          2       1163       1719       75118

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84     (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  LOAD AS SELECT  (cr=1257 pr=2 pw=1066 time=554942 us)
     75118      75118      75118   TABLE ACCESS FULL T (cr=1106 pr=0 pw=0 time=105001 us cost=315 size=13027100 card=82450)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                         2        0.00          0.00
  Disk file operations I/O                        1        0.00          0.00
  direct path sync                                1        0.21          0.21
********************************************************************************

时间: 2024-07-30 10:50:13

[20150629]物化视图刷新atomic_refresh.txt的相关文章

[20150705]12c物化视图刷新Out of place2

[20150705]12c物化视图刷新Out of place2.txt --11G物化视图刷新有1个参数atomic_refresh. --如果为false,采用的方式是truncate,再使用/*+ append */ 提示insert.这样redo最少,但是刷新期间无法访问. --如果为true,采用的方式是delete,再insert.这样产生许多redo与undo.这样在刷新期间访问没问题,最多有点慢. --自己做一个测试: --12c在这个基础上引入1个参数Out of place,

物化视图刷新原理与性能诊断

参考文档:Materialized View Refresh: Locking, Performance, Monitoring (文档 ID 258252.1) How to Monitor the Progress of a Materialized View Refresh (MVIEW) (文档 ID 258021.1) 1.名词解释: 基表 指的是英文里面的Master Table和Master Materialized View,并不只是只一个表,而是创建MView的时候所需要用到的

[20150610]使用物化视图同步数据.txt

[20150610]使用物化视图同步数据.txt --昨天听别人的一个需求要同步一个表的数据,要求使用golden gate有点小题大作.实际上物化事务就可以了,自己以前做过一些测试,也 --许没做记录,这次做一个记录. 1.建立测试环境: --源数据库10g  10.2.0.4.0  IP=192.168.100.89 --同步表T. create table t ( id number CONSTRAINTS pk_t primary key , name varchar2(20)); in

特殊的物化视图刷新

现在有一个需求,某个环境中存在两个用户,一个用户中存在物化视图,另一个用户中存在源表,根据业务的需要,需要做一种特别的物化视图刷新. 物化视图用户中的物化视图为CORP_NAME 源数据用户中的表为ADD_CORP_NAME 可能数据刷新是没有问题,关键就是在于CORP_NAME中的字段要比ADD_CORP_NAME多一些.CORP_NAME           ADD_CORP_NAME CORP_ID               |  CORP_ID            SYS_CREAT

物化视图刷新结合ADG的尝试

之前写过一篇 物化视图刷新结合ADG的尝试,想必绝大多数的朋友看完再没有深究,其实也有些朋友做了建议,让我尝试prebuilt来做.这种数据迁移方式用的比较少,但是个人感觉还是很不错的.如果迁移的表不是很多,这种迁移方式还是非常强大的. 如果一个表非常大,我目前的设想就是通过ADG备库来把数据首先同步到统计库中,然后在主库端通过物化视图日志来增量刷新. 使用物化视图 prebuilt的方式确实可以实现,我产生了几个疑问,物化视图日志该什么时候创建.创建的时间太早或者太晚,对于增量刷新是否有影响,

oracle如何利用触发器对物化视图刷新进行定制

物化视图的刷新其实和普通的SQL执行没有什么本质的区别,因此也可以通过在物化视图上创建触发器的方式,对刷新操作进行定制. 正好前两天有人在BLOG上问我,如果在物化视图添加一个时间戳列,并在物化视图更新的时候,自动维护这个列.其实很简单,通过触发器就可以达到这个目的: SQL> CREATE TABLE T (ID NUMBER PRIMARY KEY, NAME VARCHAR2(30)); 表已创建. SQL> INSERT INTO T SELECT ROWNUM, TNAME FROM

物化视图刷新失败导致日志表异常增大

整理自:http://blog.itpub.net/231499/viewspace-63714/ 今天在检查时,发现某个物化视图日志占用的空间超过150M,再检查看,该物化视图日志表的记录数有150W,由于其对应的物化视图没有会刷新一次,结合业务量分析可知:物化视图日志不能正常清除. 下面的解决步骤 --在源库查询物化视图对应日志条目个数SQL> select count(1) from MLOG$_ITEM_TAG; COUNT(1)----------532515 --在物化视图端刷新物化

物化视图刷新的问题及分析

最近现场需要搭建一套全新的环境,对于数据字典的管理采用了物化视图,因为数据量不大,采用了全量刷新的方式.因为有好几套环境,有几套环境是通过db link和主节点的表创建的物化视图,这几个节点间的网络情况不好,刷新一个稍微大一些的表或者带有lob字段的表时,速度会很慢,因为有好几套环境,一套一套的等待刷新完得花费不少的时间,所以自己想写一个shell脚本让它在后台慢慢跑,这样过一段时间再看看日志保证数据都已经刷新完毕就可以了. 原本采用的方式是 create materialized view x

【物化视图】根据物化视图日志快速刷新物化视图的过程

先来再次分析一下物化视图日志的结构. yang@rac1>create table t (id number ,name varchar2(30),val number); Table created. yang@rac1>create materialized view log on t with rowid,sequence (id,name) including  new values; Materialized view log created. yang@rac1>desc m