Comments on: fast refresh of join-only materialized views – algorithm summary

By: Alberto Dell’Era’s Oracle blog » fast refresh of join-only MVs: _mv_refresh_use_stats and locking log stats

Thu, 11 Mar 2010 20:46:21 +0000

[...] understand the importance of points 5 and 6, please check this post of mine; note how those indexes are a necessary prerequisite for the sanity of the DEL and INS steps of the [...]

By: Alberto Dell’Era’s Oracle blog » 11gR2: materialized view logs changes

Tue, 03 Nov 2009 17:20:55 +0000

[...] the refresh is performed by using a “mark-and-propagate” algorithm, which is essentially (check this post for some additional details): 1) new log rows are inserted with snaptime$$=4000 A.D; 2) at refresh [...]

By: Blogroll Report 31/07/2009 – 07/08/2009 « Coskan’s Approach to Oracle

Blogroll Report 31/07/2009 – 07/08/2009 « Coskan’s Approach to Oracle — Wed, 12 Aug 2009 14:32:37 +0000

[...] Alberto Dell’Era- fast refresh of join-only materialized views -algorithm summary [...]

By: Alberto Dell'Era

Alberto Dell'Era — Tue, 11 Aug 2009 15:58:47 +0000

@Cristian I have posted an investigation about your scenario.

By: Alberto Dell’Era’s Oracle blog » fast refresh of single-table materialized views - algorithm summary

Tue, 11 Aug 2009 15:57:13 +0000

[...] might be considered a degenerate case of a join-only MV, a topic that we investigated in an earlier post, and one could expect the same algorithm. But that is not the case: the test case shows that the [...]

By: Alberto Dell'Era

Alberto Dell'Era — Fri, 07 Aug 2009 17:07:45 +0000

I know a “rowid MV”, as your one is, cannot contain neither joins neither aggregates and must be based on a single table, so they probably use a different algorithm than the one examined in this post (which is for join-only MVs). They are in fact MVs used for replication almost exclusively, usually from a remote database to a local one through a dblink – the old name was “snapshots”, a technology “now merged” with the “materialized view” one. So it is outside the scope of this post, albeit I’ve added an investigation about this on my to-do list. It makes sense, anyway, that on a scenario as simple as this one, they have tried to optimize the propagation (hence using UPDATEs) as much as possible (especially to minimize the traffic over the dblink).

By: Cristian

Cristian — Fri, 07 Aug 2009 14:30:00 +0000

Sorry, the sun on my head :)

create table testmv1 (pk1 number,fld1 varchar2(10));
create materialized view log on testmv1 with rowid;

create materialized view test_mv1
build immediate
refresh fast with rowid
on demand
as
 select
  testmv1.*
 from testmv1;

I’ve not tried with primary key based refresh.

By: Alberto Dell'Era

Alberto Dell'Era — Fri, 07 Aug 2009 14:16:12 +0000

Ok, but what is the defining SQL statement of the MV TEST_MV1 ?

By: Cristian

Cristian — Fri, 07 Aug 2009 14:12:26 +0000

I meant without aggregates:

update testmv1 set fld1='a2' where pk1=1;
commit;
EXEC DBMS_MVIEW.REFRESH('TEST_MV1');
SELECT * FROM TESTMV1_LOG;

This because we sometimes use MV’s as data replication tool.

By: Alberto Dell'Era

Alberto Dell'Era — Fri, 07 Aug 2009 13:24:58 +0000

@Cristian

what do you mean by “simple MV”, with or without aggregates ?

You might want to post the defining SQL statement of the MV …