Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Materialized View Refresh On Commit

Suppose I have a table TABLE with two columns COL_1 and COL_2.

I have a materialized view that simply reads TABLE.COL_1, and is set for: REFRESH FAST ON COMMIT.

If I update TABLE.COL_2, does the materialized view refresh?

like image 792
Johnny5 Avatar asked Mar 04 '11 21:03

Johnny5


People also ask

How do you automatically refresh a materialized view?

You can also use the AUTO REFRESH clause to refresh materialized views automatically. For more information about creating materialized views, see CREATE MATERIALIZED VIEW. You can turn on autorefresh for a current materialized view by using ALTER MATERIALIZED VIEW.

Do materialized views update automatically?

By default, materialized views in Redshift must be manually refreshed, but an AUTO REFRESH option will attempt to update the view when base data changes.

What is on commit refresh?

ON COMMIT : The refresh is triggered by a committed data change in one of the dependent tables. ON DEMAND : The refresh is initiated by a manual request or a scheduled task.

Why is my materialized view not refreshing automatically?

If you want the materialized view to be refreshed automatically you should use ON COMMIT refresh method. Since you have specified an ON DEMAND refresh you will have to manually refresh the materialized view using DBMS_MVIEW. REFRESH method. There are lot of considerations for refreshing a materialized view.


1 Answers

Yes, it appears that updating COL_2 also refreshes the view.

Updating COL_2 uses more resources than a comparable update on a similar table without a materialized view. And updating COL_2 will update the row timestamp (ORA_ROWSCN) of the materialized view.

-------
--Compare the amount of work done to update.
--The difference isn't huge, but is significant and consistent.
-------

--Create table and materialized view
create table table1 (col_1 number primary key, col_2 number);
create materialized view log on table1;
create materialized view table1_mv refresh fast on commit
  as select col_1 from table1;
insert into table1 values(1, 1);
commit;

--Create a regular table for comparison
create table table2 (col_1 number primary key, col_2 number);
insert into table2 values(1, 1);
commit;

--Parse the queries so traces won't count that work.
update table1 set col_1 = 2;
update table1 set col_2 = 2;
update table2 set col_1 = 2;
update table2 set col_2 = 2;
rollback;

set autotrace on
alter system flush buffer_cache;
update table1 set col_1 = 2;
--         11  db block gets
--          8  consistent gets
--         13  physical reads

rollback;
alter system flush buffer_cache;
update table1 set col_2 = 2;
--          6  db block gets
--          8  consistent gets
--         12  physical reads

rollback;
alter system flush buffer_cache;    
update table2 set col_1 = 2;
--          7  db block gets
--          7  consistent gets
--          9  physical reads

rollback;
alter system flush buffer_cache;
update table2 set col_2 = 2;
--          3  db block gets
--          7  consistent gets
--          8  physical reads

set autotrace off


-------
--Compare ORA_ROWSCN.
--The times are different, implying the materialized view was modified.
-------

--(You may need to run these steps slowly to reproduce.  ORA_ROWSCN is
--not perfect, sometimes you'll see the same timestamp.)
select scn_to_timestamp(ora_rowscn) from table1_mv;
    --3/5/2011 12:25:25.000000000 AM
update table1 set col_1 = 3;
commit;
select scn_to_timestamp(ora_rowscn) from table1_mv;
    --3/5/2011 12:25:37.000000000 AM
update table1 set col_2 = 3;
commit;
select scn_to_timestamp(ora_rowscn) from table1_mv;
    --3/5/2011 12:25:46.000000000 AM
like image 65
Jon Heller Avatar answered Nov 02 '22 22:11

Jon Heller