MATERIALIZED VIEW

MATERIALIZED VIEWSA Materialized View is effectively a database table that contains the results of a query. The power of materialized views comes from the fact that, once created, Oracle can automatically synchronize a materialized view's data with its source information as required with little or no programming effort. Materialized views can be used for many purposes, including:

Denormalization Validation Data Warehousing Replication

Views vs Materialized ViewsLike its predecessor the view, materialized views allow you to store the definition of a query in the database.

VIEW VS. MATERIALIZED VIEWTable select * from T ;  KEY VAL---------- ----- 1 a 2 b 3 c 4 

Viewcreate view v

asselect *from t ; select * from V ;  KEY VAL---------- ----- 1 a 2 b 3 c 4

Materialized View

create materialized view mv

asselect *from t ; select * from MV ;  KEY VAL---------- ----- 1 a 2 b 3 c 4 

ROWIDTableselect rowedfrom Torder by rowid ; ROWID------------------AAAgY9AAEAAAAVfAAAAAAgY9AAEAAAAVfAABAAAgY9AAEAAAAVfAACAAAgY9AAEAAAAVfAAD 

Viewselect rowidfrom Vorder by rowid ; ROWID------------------AAAgY9AAEAAAAVfAAAAAAgY9AAEAAAAVfAABAAAgY9AAEAAAAVfAACAAAgY9AAEAAAAVfAAD 

Materialized Viewselect rowidfrom MVorder by rowid ; ROWID------------------AAAgZFAAEAAADyEAAAAAAgZFAAEAAADyEAABAAAgZFAAEAAADyEAACAAAgZFAAEAAADyEAAD 

DIFFERENCETableupdate t set val =

upper(val); select * from T ;  KEY VAL---------- ----- 1 A 2 B 3 C 4 

View

select * from V ;  KEY VAL---------- ----- 1 A 2 B 3 C 4 

Materialized View

select * from MV ;  KEY VAL---------- ----- 1 a 2 b 3 c 4 

REFRESHING MATERIALIZED VIEW

EXECUTE DBMS_MVIEW.REFRESH( 'MV' );Table

 select * from T ;  KEY VAL---------- ----- 1 A 2 B 3 C 4

 

View

select * from V ;  KEY VAL---------- ----- 1 A 2 B 3 C 4 

Materialized View

select * from MV ;  KEY VAL---------- ----- 1 A 2 B 3 C 4 

DROP MATERIALIZED VIEWdrop materialized view mv ; drop view v ; update t set val = lower(val); commit;

REFRESH COMPLETEThere are various ways to refresh the data in a materialized view, the simplest way being a complete refresh. When a complete refresh occurs the materialized view's defining query is executed and the entire result set replaces the data currently residing in the materialized view. The REFRESH COMPLETE clause tells Oracle to perform complete refreshes by default when a materialized view is refreshed.

create materialized view mv REFRESH COMPLETE as select * from t;

REFRESH COMPLETELet's see a complete refresh in action now. We will use the DBMS_MVIEW.REFRESH procedure to initiate it. The "list" parameter accepts a list of materialized views to refresh (in our case we only have one) and the "method" parameter accepts a "C", for Complete refresh.

select key, val, rowid from mv ;

KEY VAL ROWID---------- ----- ------------------

1 a AAAWgHAAEAAAAIEAAA 2 b AAAWgHAAEAAAAIEAAB 3 c AAAWgHAAEAAAAIEAAC 4 AAAWgHAAEAAAAIEAAD

REFRESH COMPLETE execute DBMS_MVIEW.REFRESH( LIST =>

'MV', METHOD => 'C' ); select key, val, rowid from mv ;

KEY VAL ROWID---------- ----- ------------------ 1 a AAAWgHAAEAAAAIEAAE 2 b AAAWgHAAEAAAAIEAAF 3 c AAAWgHAAEAAAAIEAAG 4 AAAWgHAAEAAAAIEAAH

Note how the rowids in the second query differ from those of the first, even though the data in table T was unchanged throughout. This is because complete refreshes create a whole new set of data, even when the new result set is identical to the old one.

Cleanup

drop materialized view mv ;

MATERIALIZED VIEW LOGSComplete refreshes of materialized views can be expensive operations. Fortunately there is a way to refresh only the changed rows in a materialized view's base table. This is called fast refreshing. Before a materialized view can perform a fast refresh however it needs a mechanism to capture any changes made to its base table. This mechanism is called a Materialized View Log. describe T

Name Null? Type -------------------------------------------- -------- ------------------------------ KEY NOT NULL NUMBER VAL VARCHAR2(5)

create materialized view log on t ;Note how the materialized view log is not given a name. This is because a table can only ever have one materialized view log related to it at a time, so a name is not required.

MATERIALIZED VIEW LOGSTo see what a materialized view log looks like we can examine the table used to implement it. In practice developers other than Dizwell never actually need to reference this table, but showing it here helps illustrate materialized view log behaviour.

describe MLOG$_T Name Null? Type -------------------------------------------- -------- ------------------------------ KEY NUMBER SNAPTIME$$ DATE DMLTYPE$$ VARCHAR2(1) OLD_NEW$$ VARCHAR2(1) CHANGE_VECTOR$$ RAW(255)

The MLOG$_T.KEY column mirrors the base table's primary key column T.KEY. The other MLOG$ columns are system generated.

select * from MLOG$_T ;no rows selected

MATERIALIZED VIEW LOGS The query above shows that a materialized view log is initially empty upon creation.

Rows are automatically added to MLOG$_T when base table T is changed.

UPDATE t set val = upper( val ) where KEY = 1 ;

INSERT into t ( KEY, val ) values ( 5, 'e' );

column dmltype$$ format a10

select key, dmltype$$ from MLOG$_T ;

KEY DMLTYPE$$---------- ----------

1 U 5 I

If the changes affecting T are rolled back, so are the changes to MLOG$_T.

create materialized view log on t WITH PRIMARY KEY ;

desc mlog$_t Name Null? Type -------------------------------------------- -------- ------------------------------ KEY NUMBER SNAPTIME$$ DATE DMLTYPE$$ VARCHAR2(1) OLD_NEW$$ VARCHAR2(1) CHANGE_VECTOR$$ RAW(255)

Note how MLOG$_T contains T's primary key column, T.KEY. This materialized view log is equivalent to the one created earlier in this topic, which did not have a WITH clause, because WITH PRIMARY KEY is the default option when no WITH clause is specified.

ROLLBACK EFFECT

rollback ;Rollback complete.

select key, dmltype$$ from MLOG$_T ;

no rows selected

MATERIALIZED VIEW WITH PRIMARY KEY

To include the base table's primary key column in a materialized view log the WITH PRIMARY KEY clause can be specified.

drop materialized view log on t ;

create materialized view log on t WITH ROWID, PRIMARY KEY ;

desc mlog$_t Name Null? Type -------------------------------------------- -------- ------------------------------ KEY NUMBER M_ROW$$ VARCHAR2(255) SNAPTIME$$ DATE DMLTYPE$$ VARCHAR2(1) OLD_NEW$$ VARCHAR2(1) CHANGE_VECTOR$$ RAW(255)

In this case both KEY and M_ROW$$ appear in the log table.

MATERIALIZED VIEW WITH SEQUENCE

A special SEQUENCE column can be include in the materialized view log to help Oracle apply updates to materialized view logs in the correct order when a mix of Data Manipulation (DML) commands, e.g. insert, update and delete, are performed on multiple base tables in a single transaction.

drop materialized view log on t ;

create materialized view log on t WITH SEQUENCE ;create materialized view log on t2 WITH SEQUENCE ;

INSERT into T values ( 5, 'e' );INSERT into T2 values ( 60, 3, 300 );

UPDATE T set val = upper(val) where key = 5 ;UPDATE T2 set amt = 333 where key = 60 ;

commit;

MATERIALIZED VIEW WITH SEQUENCE select SEQUENCE$$, key, dmltype$$ from mlog$_T ; SEQUENCE$$ KEY DMLTYPE$$---------- ---------- ---------- 60081 5 I 60083 5 U

select SEQUENCE$$, key, dmltype$$ from mlog$_T2 ;

SEQUENCE$$ KEY DMLTYPE$$---------- ---------- ----------60082 60 I60084 60 U

Since mixed DML is a common occurrence SEQUENCE will be specified in most materialized view logs. In fact, Oracle recommends it.

"Oracle recommends that the keyword SEQUENCE be included in your materialized view log statement unless you are sure that you will never perform a mixed DML operation (a combination of INSERT, UPDATE, or DELETE operations on multiple tables)."

MATERIALIZED VIEW WITH COLUMN LIST

The WITH clause can also contain a list of specific base table columns. In the next snippet we include the VAL column.

drop materialized view log on t ;

create materialized view log on t WITH ( VAL );

desc mlog$_t

Name Null? Type -------------------------------------------- -------- ------------------------------ KEY NUMBER VAL VARCHAR2(5) SNAPTIME$$ DATE DMLTYPE$$ VARCHAR2(1) OLD_NEW$$ VARCHAR2(1) CHANGE_VECTOR$$ RAW(255)

MATERIALIZED VIEW WITH COLUMN LIST select * from t ; KEY VAL---------- ----- 1 a 2 b 3 c 4 5 E

UPDATE t set val = 'f' where key = 5 ;

column old_new$$ format a10

select key, val, old_new$$ from mlog$_t ;

KEY VAL OLD_NEW$$---------- ----- ---------- 5 E O

INCLUDING NEW VALUES CLAUSE In the last slides we see that the VAL column contains values as they existed before the update operation, aka the "old" value. There is no need to store the new value for an update because it can be derived by applying the change vector (a RAW value stored in CHANGE_VECTOR$$, which Oracle uses internally during refreshes) to the old value. In some situations, which we will identify in later topics, it helps to have both the old value and the new value explicitly saved in the materialized view log. We can do that using the INCLUDING NEW VALUES clause, like this.

drop materialized view log on T ;

create materialized view log on t with sequence ( VAL ) INCLUDING NEW VALUES;

INCLUDING NEW VALUES CLAUSE update t set val = 'g' where key = 5 ;

column old_new$$ format a9

select sequence$$, key, val, old_new$$ from mlog$_torder by sequence$$ ;

SEQUENCE$$ KEY VAL OLD_NEW$$---------- ---------- ----- --------- 60085 5 f O 60086 5 g N

Note how both the old and the new values are stored in the same column, VAL. The OLD_NEW$$ column identifies the value as either an old or a new value.

REFRESH FASTNow that we know how materialized view logs track changes to base tables we can use them to perform fast materialized view refreshes, i.e. refreshes where only the individual materialized view rows affected by base table changes are updated. This is also called "incremental" refreshing.

Earlier in this tutorial we saw how the rowids for each row in a materialized view changed after a complete refresh. Now let's see what happens to a materialized view's rowids after a fast refresh. First we use the REFRESH FAST clause to specify that the default refresh method should be fast.

create materialized view log on t with sequence ;

create materialized view mv REFRESH FAST as select * from t;

REFRESH FASTselect key, val, rowid from mv ;

KEY VAL ROWID---------- ----- ------------------ 1 a AAAWm+AAEAAAAaMAAA 2 b AAAWm+AAEAAAAaMAAB 3 c AAAWm+AAEAAAAaMAAC 4 AAAWm+AAEAAAAaMAAD

Now we refresh the materialized view. The "F" value for the "method" parameter ensures the refresh will be a Fast one.

execute dbms_mview.refresh( list => 'MV', method => 'F' );

select key, val, rowid from mv ;

REFRESH FASTKEY VAL ROWID---------- ----- ------------------ 1 a AAAWm+AAEAAAAaMAAA 2 b AAAWm+AAEAAAAaMAAB 3 c AAAWm+AAEAAAAaMAAC 4 AAAWm+AAEAAAAaMAAD The rowids did not change. Thus, with a fast

refresh the materialized view data is not touched when no changes have been made to the base table, unlike a complete refresh where each row would have been created a new.

REFRESH FASTNow let's update a row in the base table.

update t set val = 'XX' where key = 3 ;

commit;

execute dbms_mview.refresh( list => 'MV', method => 'F' );

select key, val, rowid from mv ;

KEY VAL ROWID---------- ----- ------------------ 1 a AAAWm+AAEAAAAaMAAA 2 b AAAWm+AAEAAAAaMAAB 3 XX AAAWm+AAEAAAAaMAAC 4 AAAWm+AAEAAAAaMAAD

Still no change in the rowids. In row 3 we can see that VAL changed from "c" to "XX" though, telling us that row 3 was updated during the refresh.

REFRESH FAST VS. COMPLETEThe REFRESH FAST clause of the CREATE MATERIALIZED VIEW command tells Oracle what type of refresh to perform when no refresh option is specified. A materialized view created with REFRESH FAST can still be refreshed completely if required though. In the following example note how, even though MV was created above with the REFRESH FAST clause, all its rowids change after the refresh. This indicates that a complete refresh was performed.

execute dbms_mview.refresh( list => 'MV', method => 'C' );

select key, val, rowid from mv ;

KEY VAL ROWID---------- ----- ------------------ 1 a AAAWm+AAEAAAAaMAAE 2 b AAAWm+AAEAAAAaMAAF 3 XX AAAWm+AAEAAAAaMAAG 4 AAAWm+AAEAAAAaMAAH

REFRESH FAST VS. COMPLETESimilarly a materialized view created with REFRESH COMPLETE can be fast refreshed (assuming the materialized view is capable of being fast refreshed, we'll learn more about this later).

drop materialized view mv ;

create materialized view mv REFRESH COMPLETE as select * from t; select key, val, rowid from mv ;

KEY VAL ROWID---------- ----- ------------------ 1 a AAAWnBAAEAAAAaMAAA 2 b AAAWnBAAEAAAAaMAAB 3 XX AAAWnBAAEAAAAaMAAC 4 AAAWnBAAEAAAAaMAAD

REFRESH FAST VS. COMPLETEexecute dbms_mview.refresh( list => 'MV', method => 'F' );

select key, val, rowid from mv ;

KEY VAL ROWID---------- ----- ------------------ 1 a AAAWnBAAEAAAAaMAAA 2 b AAAWnBAAEAAAAaMAAB 3 XX AAAWnBAAEAAAAaMAAC 4 AAAWnBAAEAAAAaMAAD

Note how none of the rowids in MV changed, indicating a fast refresh.