MATERIALIZED VIEW

MATERIALIZED VIEWS
A 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 Views Like its predecessor the view, materialized views allow you to store the definition of a query in the database.

VIEW VS. MATERIALIZED VIEW

Table View create view v as select * from t ; select * from V ; Materialized View create materialized view mv as select * from t ;

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

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

ROWID
Table select rowed from T order by rowid ; ROWID -----------------AAAgY9AAEAAAAVfAAA AAAgY9AAEAAAAVfAAB AAAgY9AAEAAAAVfAAC AAAgY9AAEAAAAVfAAD View select rowid from V order by rowid ; ROWID -----------------AAAgY9AAEAAAAVfAAA AAAgY9AAEAAAAVfAAB AAAgY9AAEAAAAVfAAC AAAgY9AAEAAAAVfAAD Materialized View select rowid from MV order by rowid ; ROWID -----------------AAAgZFAAEAAADyEAAA AAAgZFAAEAAADyEAAB AAAgZFAAEAAADyEAAC AAAgZFAAEAAADyEAAD

DIFFERENCE
Table update t set val = upper(val); select * from T ; View Materialized View

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

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

KEY VAL ---------- ----1A 2B 3C 4

REFRESHING MATERIALIZED VIEW

EXECUTE DBMS_MVIEW.REFRESH(
Table View

'MV' );

Materialized View

select * from T ;

select * from V ;

select * from MV ;

KEY VAL ---------- ----1A 2B 3C 4

KEY VAL ---------- ----1A 2B 3C 4

KEY VAL ---------- ----1A 2B 3C 4

DROP MATERIALIZED VIEW

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

REFRESH COMPLETE
There 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 COMPLETE as select * from t;

REFRESH

REFRESH COMPLETE
Let'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 LOGS

Complete 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
-------------------------------------------KEY VAL

Null?
--------

Type
------------------------------

NOT NULL NUMBER 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 LOGS

To 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 KEY SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$ Null? Type NUMBER DATE VARCHAR2(1) VARCHAR2(1) 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$$ ---------- ---------1U 5I 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 KEY M_ROW$$ SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$ Null? Type NUMBER VARCHAR2(255) DATE VARCHAR2(1) VARCHAR2(1) 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 5I 60083 5U select SEQUENCE$$, key, dmltype$$ from mlog$_T2 ;
SEQUENCE$$ ---------60082 60084 KEY ---------60 60 DMLTYPE$$ ---------I 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 -------------------------------------------KEY VAL SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$ Null? -------Type -----------------------------NUMBER VARCHAR2(5) DATE VARCHAR2(1) VARCHAR2(1) RAW(255)

MATERIALIZED VIEW WITH COLUMN LIST

select * from t ; KEY VAL ---------- ----1a 2b 3c 4 5E 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$_t order by sequence$$ ; SEQUENCE$$ KEY ------------------- ----60085 5 f 60086 5 g VAL OLD_NEW$$ --------O 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 FAST
Now 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 FAST
select 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 FAST
KEY 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 FAST
Now 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 ---------- ----- -----------------1a AAAWm+AAEAAAAaMAAA 2b 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. COMPLETE

The 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 ---------1 2 3 4 VAL ----a b XX ROWID -----------------AAAWm+AAEAAAAaMAAE AAAWm+AAEAAAAaMAAF AAAWm+AAEAAAAaMAAG AAAWm+AAEAAAAaMAAH

REFRESH FAST VS. COMPLETE

Similarly 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 ---------1 2 3 4 VAL ----a b XX ROWID -----------------AAAWnBAAEAAAAaMAAA AAAWnBAAEAAAAaMAAB AAAWnBAAEAAAAaMAAC AAAWnBAAEAAAAaMAAD

REFRESH FAST VS. COMPLETE

execute dbms_mview.refresh( list => 'MV', method => 'F' ); select key, val, rowid from mv ; KEY VAL 1 a 2 b 3 XX 4 ROWID -----------------AAAWnBAAEAAAAaMAAA AAAWnBAAEAAAAaMAAB AAAWnBAAEAAAAaMAAC AAAWnBAAEAAAAaMAAD

---------- -----

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