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?
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.
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.
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.
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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With