探讨实体化视图的刷新机制
2024-07-21 02:06:46
供稿：网友
探讨实体化视图的刷新机制
author：kamus
mail：[email protected]
date：2004年10月
今天给客户搭建历史查询服务器，用oracle8i的snapshot实现，也就是9i的实体化视图。
顺手做了一下trace，看了一下刷新时候oracle后台是怎么工作的。
前期准备，使用dbms_support包，这个包默认是没有安装的，需要运行下面的命令来手动安装。
sql>conn / as sysdba
sql>@?/rdbms/admin/dbmssupp.sql
sql>grant execute on dbms_support to kamus;
sql>create public synonym dbms_support for dbms_support;
先看快速刷新，测试表是t1，创建了快照日志，用于刷新的视图是mv_t1，用户是kamus
执行trace：
sql>conn kamus
sql>exec dbms_support.start_trace(waits=>true,binds=>true);
sql>exec dbms_mview.refresh(list => 'mv_t1');
sql>exec dbms_support.stop_trace;
然后tkprof生成trace结果的报表，下面只是节选了其中一部分。
执行一次dbms_mview.refresh，oracle后台会执行13个 user sql和92个 internal sql，实在是一个繁杂的工作。
1。开始刷新
begin dbms_mview.refresh(list => 'mv_t1'); end;
2。检查snap$表，确认当前用户是否有需要刷新的视图
3。在dbms_lock_allocated数据字典中更新记录，设置过期时间
update dbms_lock_allocated set expiration = sysdate + (:b1 /86400)
where
rowid = :b2
4。检查可能会用到的dblink和一些高级队列的数据字典
5。检查表的相关约束
6。检查几个初始化参数的值，包括_enable_refresh_schedule，_delay_index_maintain，compatible
7。将mlog中所有没有标志为定时刷新的记录更新为立刻刷新
update "kamus"."mlog$_t1" set snaptime$$ = :1
where
snaptime$$ > to_date('2100-01-01:00:00:00','yyyy-mm-dd:hh24:mi:ss')
8。重新编译mv_t1实体化视图
alter summary "kamus"."mv_t1" compile
这一步比较可疑，sql中是没有alter summary找个命令的，如果是编译的话，那么就可能锁定对象，就有可能产生library cache lock
9。检查要执行的sql文，这一步比较有趣
select operation#, cols, sql_txt, tabnum, fcmaskvec, ejmaskvec, setnum
from
sys.snap_refop$ where ((operation# >= 0 and operation# <= 6) or operation#
in (10, 12, 13)) and sowner = :1 and vname = :2 and instsite = :3 order
by tabnum, setnum, operation#
对于一个mv刷新将会使用到sql全部存在这张表中。
如果是fast刷新，那么对于查询mlog表，查询基表的数据，insert、update、delete实体化视图都分别有一句sql。
其中operation#字段值的常见含义如下：
0：查询mlog表
1：对于实体化视图的delete操作
2：查询基表的最新数据
3：对于实体化视图的update操作
4：对于实体化视图的insert操作
如果是complete刷新，那么只有一条记录，是基于基表的全表insert操作，operation#是7。
此处的执行计划显示是对于snap_refop$的全表扫描，如果系统中存在大量需要refresh的实体化视图，无疑是影响性能的。
10。取得需要更新的记录主键
select distinct log$."idate"
from
(select mlog$."idate" from "kamus"."mlog$_t1" mlog$ where "snaptime$$" > :1
and ("dmltype$$" != 'i')) log$ where (log$."idate") not in (select
mas_tab$."idate" from "t1" "mas_tab$" where log$."idate" = mas_tab$."idate")
注意到这里使用了distinct，也就是我们可以猜测，如果在一次刷新之前对于同一条记录作了多次的修改，那么刷新操作只需要作一次，就是获得基表中该条记录的最新值就可以了。
idate字段是我的测试表中的主键。
"dmltype$$" != 'i'表示不是insert的操作。
此处的执行计划显示对于mlog表进行了一次全表扫描，如果有大量的更新操作，无疑又是影响性能的一步。
11。取得基表中当前需要刷新的记录所有字段的最新值
select current$."idate",current$."c"
from
(select "t1"."idate" "idate","t1"."c" "c" from "t1" "t1") current$, (select
distinct mlog$."idate" from "kamus"."mlog$_t1" mlog$ where "snaptime$$" >
:1 and ("dmltype$$" != 'd')) log$ where current$."idate" = log$."idate"
这一步操作表示，mlog中只存储修改操作涉及到的记录主键，其它的字段值仍然会到基表中去作查询。
此处的执行计划显示对于mlog表再一次作了全表扫描。
12。用取得的最新值更新实体化视图
update "kamus"."mv_t1" set "idate" = :1,"c" = :2
where
"idate" = :1
这一步仍然比较奇怪，因为我的测试中只作了insert，并没有update的操作，莫非oracle在刷新时，并不管是否存在update的操作，都会例行作一次视图数据的更新？不过此处更新会使用实体化视图中的主键，速度应该时很快的。
13。将取得的最新值插入到实体化视图中
insert into "kamus"."mv_t1" ("idate","c")
values
(:1,:2)
这步才到了真正要实现的目的上，呵呵。
14。更新一批数据字典，表明刷新已经完成
15。删除mlog表中已经刷新过的记录
delete from "kamus"."mlog$_t1"
where
snaptime$$ <= :1
这一步操作是比较耗费资源的，使用delete，产生redo和undo，无法降低mlog表的hwm标志，同时又是一次全表扫描，如果经常有大量更新发生，最好能定时作mlog表的truncate动作，否则这一步操作可能会越来越慢。
至此，一次实体化视图的快速刷新算是完全结束了。
我们继续看一下完全刷新的后台机制。
1-8步跟快速刷新基本相同。
9。检查要执行的sql文
select operation#, cols, sql_txt
from
sys.snap_refop$ where operation# = 7 and sowner = :1 and vname = :2 and
instsite = :3
可以看到直接去找operation# = 7的sql了，这就是完全刷新需要使用的sql。
10。检查完全刷新涉及到的约束，索引，触发器
11。删除实体化视图中的原有数据
delete from "kamus"."mv_t"
这一步让我很诧异，记得文档中说应该是truncate操作，但是此处显示的是delete？这样的话，完全刷新的代价实在是很大了。
12。插入基表中所有数据
insert /*+ bypass_recursive_check */ into "kamus"."mv_t"("x") select "t"."x"
from "t" "t"
这里使用到的提示/*+ bypass_recursive_check */，是不是在实际应用中可以提高insert的效率呢？
13。更新一批数据字典，表明刷新已经完成
14。如果在基表上创建了刷新日志mlog表，那么oracle不管这次刷新是不是完全刷新，都会去作一次删除mlog表中数据的操作。如果没有创建过mlog，那么这一步将被省略。所以如果决定使用完全刷新，那么就不要在基表上创建刷新日志了，省得无谓的资源消耗。
