1. Chapter 15
Materialized Views

2. Materialized Views (MVs)
Sometimes people new to MVs are confused by the term “materialized view”.
An MV is basically a table that is periodically refreshed with data from a SQL query.
Oracle provides numerous configurations and management features for MVs.
Fairly robust and flexible feature that has been available since version 7.

3. Primary Uses for MVs
Replicating of data to offload query workloads to separate reporting databases.
Improving performance of queries by periodically computing and storing the results of complex aggregations of data, which lets users query point-in-time results (of the complex queries).

4. Basic Materialized View Create Statemetn
This is a complete refresh, on demand MV based on query that selects from the SALES table:
create materialized view sales_mv
segment creation immediate
refresh
complete
on demand as
select
sales_amt
,sales_dtt
from sales;

5. Using the Complete Refresh Mechanism
Data is deleted from the underlying table.
MV is completely refreshed with data from the base table.
SQL> exec dbms_mview.refresh('SALES_MV','C');

6. Complete Refresh Architectural Steps
Users/applications create transactions.
Data is committed in the base table.
A complete refresh is manually initiated with the DBMS_MVIEW package.
Data in the underlying MV is deleted and completely refreshed with the contents of the base table.
Users can query data from the MV, which contains a point-in-time snapshot of the base table’s data.

7. Complete Refresh Architectural Components

8. Creating a Fast Refreshable MV
Create a base table (if it’s not already created).
Create an MV log on the base table.
Create an MV as fast-refreshable.
SQL> create materialized view log on sales with primary key;
create materialized view sales_mv
segment creation immediate
refresh
with primary key
fast
on demand as
select
sales_id, sales_amt, sales_dtt
from sales;

9. Using the Fast Refresh Mechanism
MV log is a table that stores incremental changes to the data in the base table.
MV log is created on the base table.
Since the base table has an MV log, the MV can be fast refreshed, meaning that only the data changes since the last time the MV was refreshed need to be applied.
SQL> exec dbms_mview.refresh('SALES_MV','F');

10. Fast Refresh Architecture Steps
Users create transactions.
Data is committed in the base table.
An internal trigger on the base table populates the MV log table.
A fast refresh is initiated via the DBMS_MVIEW package.
DML changes that have been created since the last refresh are applied to the MV. Rows no longer needed by the MV are deleted from the MV log.
Users can query data from the MV, which contains a point-in-time snapshot of the base table’s data.

11. Fast Refresh Architectural Components

12. MV and MV Log are instantiated as tables
Most database features that apply to tables can be applied to MVs and MV logs:
Storage and tablespace placement
Indexing
Partitioning
Compression
Encryption
Logging
Parallelism

13. Specifying Storage Attributes for an MV
create materialized view inv_mv
pctused 95
pctfree 5
tablespace mv_data
using index tablespace mv_index as
select
inv_id
,inv_desc
from inv;

14. Creating Indexes on MVs
MV stores data in a database table.
You can create indexes on this MV to improve performance.
For example, if there is a column in an MV that is heavily referenced in WHERE clauses of SQL statements, then consider creating an index on this column (especially if it is highly selectable):
SQL> create index inv_mv_idx1 on inv_mv(region_id) tablespace mv_index;

15. Partitioning Materialized Views
You can partition an MV table like any other regular table in the database.
If you work with large MVs, you may want to consider partitioning to better manage and maintain a large table.
Use the PARTITION clause when you create the MV.
This example builds an MV that is partitioned by range on the DATE_ID column:
create materialized view inv_mv
partition by range (date_id)
(partition p1 values less than ( )
,partition p2 values less than ( )
,partition p3 values less than ( ))
refresh on demand complete with rowid as
select
inv_id, inv_desc,date_id
from inv;

16. Compressing a Materialized View
When you create an MV, an underlying table is created to store the data.
Because this table is a regular database table, you can implement features such as compression. For example:
create materialized view inv_mv
compress as
select
inv_id
,inv_desc
from inv;

17. Encrypting Materialized View Columns
When you create an MV, an underlying table is created to store the data.
Because this table is a regular database table, you can implement features such as encryption of columns. For example:
create materialized view inv_mv
(inv_id encrypt no salt
,inv_desc encrypt) as
select
inv_id inv_id
,inv_desc inv_desc
from inv;

18. Building a Materialized View on a Prebuilt Table
In data-warehouse environments, sometimes you need to create a table, populate it with large quantities of data, and then transform it into an MV. Listed next are the steps for building an MV on a prebuilt table:
Create a table.
Populate it with data.
Create an MV on the table created in step 1.

19. Creating an Unpopulated Materialized View
When you create an MV, you have the option of instructing Oracle whether or not to initially populate the MV with data.
For example, if it takes several hours to initially build an MV, you may want to first define the MV and then populate it as a separate job.
Use the BUILD DEFERRED clause to instruct Oracle not to initially populate the MV with the results of the query:
create materialized view inv_mv
tablespace mv_data
build deferred
refresh complete on demand as
select
inv_id
,inv_desc
from inv;

20. Creating a Materialized View Refreshed on Commit
Use ON COMMIT when you need the data from the master table immediately reflected in the MV.
Consider the overhead and availability issues before implementing this type of MV.
create materialized view inv_mv
refresh
on commit as
select inv_id, inv_desc from inv;

21. Creating a Never-Refreshable Materialized View
You may never want an MV to be refreshed. For example, you may want to guarantee that you have a snapshot of table at a point in time for auditing purposes.
Specify the NEVER REFRESH clause when you create the MV to achieve this:
create materialized view inv_mv
tablespace mv_data
using index tablespace mv_index
never refresh as
select
inv_id
,inv_desc
from inv;

22. Creating Materialized Views for Query-Rewrite
Query rewrite allows the optimizer to recognize that an MV can be used to fulfill the requirements of a query instead of using the underlying master (base) tables.
When users frequently write their own queries and are unaware of the available MVs, this feature can help greatly with performance.
create materialized view sales_mv
tablespace mv_data
using index tablespace mv_index
enable query rewrite as
select
sum(sales_amt), b.reg_desc
from sales a, region b
where a.region_id = b.region_id
group by b.reg_desc;

23. Creating a Fast-Refreshable MV Based on a Complex Query
In many situations, when you base an MV on a query that joins multiple tables, it’s deemed complex, and therefore is available only for a complete refresh.
However, in some scenarios, you can create a fast-refreshable MV when you reference two tables that are joined together in the MV query.
Use the EXPLAIN_MVIEW procedure of the DBMS_MVIEW to determine whether it’s possible to fast-refresh a complex query.

24. Viewing Materialized View DDL
To quickly view the SQL query on which an MV is based, select from the QUERY column of DBA/ALL/USER_MVIEWS.
If you’re using SQL*Plus, first set the LONG variable to a value large enough to display the entire contents of a LONG column:
SQL> set long 5000
SQL> select query from dba_mviews where mview_name=UPPER('&&mview_name');
To view the entire Data Definition Language ()DDL required to re-create an MV, use the DBMS_METADATA package:
SQL> select dbms_metadata.get_ddl('MATERIALIZED_VIEW','INV_MV') from dual;

25. Dropping a Materialized View
You may occasionally need to drop an MV. Perhaps a view is no longer being used, or you need to drop and re-create an MV to change the underlying query on which the MV is based (such as adding a column to it).
Use the DROP MATERIALIZED VIEW command to drop an MV.
SQL> drop materialized view orders_mv;

26. Re-creating a Materialized View to Reflect Base-Table Modifications
There is no ALTER MATERIALIZED VIEW ADD/DROP/MODIFY <column> statement, you must do the following to add/delete columns in an MV:
Alter the base table.
Drop and re-create the MV to reflect the changes in the base table.

27. Altering a Materialized View but Preserving the Underlying Table
When you drop an MV, you have the option of preserving the underlying table and its data.
You may find this approach advantageous when you’re working with large MVs in data-warehouse environments. Here are the steps:
Alter the base table.
Drop the MV, but preserve the underlying table.
Modify the underlying table.
Re-create the MV using the ON PREBUILT TABLE clause.

28. Altering a Materialized View Created on a Prebuilt Table
If you originally created an MV using the ON PREBUILT TABLE clause, then here are the steps for modifying an MV that was created using the ON PREBUILT TABLE clause:
Alter the base table.
Drop the MV. For MVs built on prebuilt tables, this doesn’t drop the underlying table.
Alter the prebuilt table.
Re-create the MV on the prebuilt table.

29. Toggling Redo Logging on a Materialized View
In some scenarios you can easily recreate an MV, and know that you don’t ever need to recover any of its data (because you can always re-create from the master table).
By default, redo logging is enabled when you create an MV. You have the option of specifying that redo not be logged when an MV is refreshed:
create materialized view inv_mv
nologging
tablespace mv_data
using index tablespace mv_index as
select
inv_id
,inv_desc
from inv;

30. Altering Parallelism
Sometimes an MV is created with a high degree of parallelism to improve the performance of the creation process.
SQL> alter materialized view inv_mv parallel 3;

31. Managing Materialized View Logs
MV logs are required for fast-refreshable MVs.
The MV log is a table that stores DML information for a master (base) table.
It’s created in the same database as the master table with the same user that owns the master table.
You need the CREATE TABLE privilege to create an MV log.
The MV log is populated by an Oracle internal trigger (that you have no control over).
This internal trigger inserts a row into the MV log after an INSERT, UPDATE, or DELETE on the master table.

32. Creating a Materialized View Log
Fast-refreshable views require an MV log to be created on the master (base) table.
Use the CREATE MATERIALIZED VIEW LOG command to create an MV log.
This example creates an MV log on the USERS table, specifying that the primary key should be used to identify rows in the MV log:
SQL> create materialized view log on users with primary key;

33. Indexing Materialized View Log Columns
Sometimes you may need better performance from your fast-refreshing MVs.
One way to do this is through indexes on columns of the MV log table. In particular, consider indexing the primary-key column and the SNAPTIME$$ column.
Oracle potentially uses two columns in WHERE clauses when refreshing an MV or purging the MV log. Here are examples of creating indexes on MV log columns:
SQL> create index mlog$_inv_idx1 on mlog$_inv(snaptime$$) tablespace mv_index;
SQL> create index mlog$_inv_idx2 on mlog$_inv(inv_id) tablespace mv_index;

34. Viewing Space Used by a Materialized View Log
You should consider periodically checking the space consumed by an MV log.
If the space consumed is growing (and never shrinking), you may have an issue with an MV not successfully refreshing (and hence causing the MV log never to be purged).
Here’s a query to check the space of MV logs:
select
segment_name
,tablespace_name
,bytes/1024/1024 meg_bytes
,extents
from dba_segments
where segment_name like 'MLOG$%'
order by meg_bytes;

35. Shrinking the Space in a Materialized View Log
You may encounter the scenario where the MV log wasn’t purged for some reason.
After resolving the issue you notice that the MV log has grown to a large size, and you want to shrink so as to free up the space it’s unnecessarily consuming:
SQL> alter table mlog$_registrations enable row movement;
SQL> alter materialized view log on registrations shrink space;

36. Checking the Row Count of a Materialized View Log
One way of detecting whether an MV log isn’t being purged is to periodically check the row counts of the MV log tables.
The following query uses SQL to generate SQL that creates a script that checks row counts for MV log tables owned by the currently connected user:
set head off pages 0 lines 132 trimspool on
spo mvcount_dyn.sql
select 'select count(*) || ' || '''' || ': ' || table_name || ''''
|| ' from ' || table_name || ';'
from user_tables
where table_name like 'MLOG%';
spo off;

37. Moving a Materialized View Log
If any MV log tables need to be relocated, use the ALTER MATERIALIZED VIEW LOG ON <table_name> MOVE statement.
Specify the name of the master table (and not the underlying MLOG$ table) on which the MV is created:
SQL> alter materialized view log on inv move tablespace tbsp2;

38. Dropping a Materialized View Log
Use the DROP MATERIALIZED VIEW LOG ON statement to drop an MV log.
You don’t need to know the name of the MV log, but you do need to know the name of the master table on which the log was created.
SQL> drop materialized view log on inv;

39. Refreshing Materialized Views
Sooner or later, you’ll need to refresh an MV manually.
Usually this is because you’re testing a refresh or troubleshooting an issue.
To do so, use SQL*Plus to call the REFRESH procedure of the DBMS_MVIEW package.
The procedure takes two parameters: the MV name and the refresh method.
This example uses the EXEC[UTE] statement to call the procedure. The MV being refreshed is INV_MV, and the refresh method is F (for fast):
SQL> exec dbms_mview.refresh('INV_MV','F');

40. Automating Refreshes Using a Shell Script and Scheduling Utility
Many MVs must be refreshed on a daily basis.
To achieve this, you can use a Linux/Unix utility such as cron that calls a shell script to refresh the MVs.
This approach
Is easy to implement and maintain
Makes it easy to create a daily log file for auditing
Sends when the job has problems or when the database isn’t available

41. Creating an MV with a Refresh Interval
When you initially create an MV, you have the option of specifying START WITH and NEXT clauses that instruct Oracle to set up an internal database job (via the DBMS_JOB package) to initiate the refresh of an MV on a periodic basis.
If you omit START WITH and NEXT, then no job is set up, and you have to use another technique (such as a scheduling utility like cron).
Example:
create materialized view inv_mv
refresh
start with sysdate+1/1440
next sysdate+1 as
select inv_id, inv_desc
from inv;

42. Efficiently Performing a Complete Refresh
Instruct Oracle to truncate the MV instead of use delete.
This may be desirable for large MV refreshes where it’s okay for the data not to be available after the truncate and before the MV is completely refreshed.
You have the option of instructing Oracle to perform the removal of data as efficiently as possible via the ATOMIC_REFRESH  parameter.
When this parameter is set to FALSE, it allows Oracle to use a TRUNCATE statement instead of a DELETE when performing a complete refresh:
SQL> exec dbms_mview.refresh('INV_MV',method=>'C',atomic_refresh=>false);

43. Handling the ORA-12034 Error
The ORA error is thrown when Oracle determines that the MV log was created after the last refresh took place in the associated MV.
In these scenarios try to perform a complete refresh of the MV.
There are several possible causes for this situation:
The MV log was dropped and re-created.
The MV log was purged.
The master table was reorganized.
The master table was truncated.
The previous refresh failed.

44. Viewing Materialized Views’ Last Refresh Times
If you work MVs, then you need to become familiar with various views used for troubleshooting.
Viewing the last refresh time is oftentimes where you start the troubleshooting process:
select
mview_name
,to_char(last_refresh_date,'dd-mon-yy hh24:mi:ss')
,refresh_mode
,refresh_method
from user_mviews
order by 2;

45. Determining Whether a Refresh Is in Progress
When troubleshooting, here’s a handy query which shows which MVs are currently refreshing:
select
sid
,serial#
,currmvowner
,currmvname
from v$mvrefresh;

46. Monitoring Real-Time Refresh Progress
The following query is extremely useful for troubleshooting MV refresh issues.
It shows where the MV is in the refresh process:
select
currmvowner_knstmvr || '.' || currmvname_knstmvr "MVIEW BEING REFRESHED",
decode(reftype_knstmvr, 1, 'FAST', 2, 'COMPLETE', 'UNKNOWN') reftype,
decode(groupstate_knstmvr, 1, 'SETUP', 2, 'INSTANTIATE',
3, 'WRAPUP', 'UNKNOWN' ) STATE,
total_inserts_knstmvr inserts,
total_updates_knstmvr updates,
total_deletes_knstmvr deletes
from x$knstmvr x
where type_knst = 6
and exists (select 1
from v$session s
where s.sid=x.sid_knst

47. Understanding Remote-Refresh Architectures
There are numerous ways to snap together various MVs to replicate data. Here is an example:

48. Determining How Many MVs Reference a Central MV Log
If an MV was dropped and unable to un-register itself from a master MV log table, then records grow indefinitely in the master MV log table.
To resolve this issue, you need information regarding which MVs are tied to which MV logs.
This query displays the master-table owner information and the SNAPID (MV ID) of all dependent MVs:
select
mowner
,master base_table
,snapid
,snaptime
from sys.slog$;

49. Creating a Materialized View Group
Sometimes for read consistency you’ll want to refresh a group of MVs.
You use the MAKE procedure of the DBMS_REFRESH package to create an MV group.
When you create an MV group, you must specify a name, a comma-separated list of MVs in the group, the next date to refresh, and the interval used to calculate the next refresh time.
Here’s an example of a group that consists of two MVs:
begin
dbms_refresh.make(
name => 'INV_GROUP'
,list => 'INV_MV, REGION_MV'
,next_date => sysdate-100
,interval => 'sysdate+1' );
end; /

50. Determining Materialized Views in a Group
When troubleshooting MV groups, it’s useful to start by displaying what the groups are and what MVs are in each group:
select
a.owner
,a.name mv_group
,b.name mv_name
from dba_rgroup a
,dba_rchild b
where a.refgroup = b.refgroup
and a.owner = b.owner
order by a.owner, a.name, b.name;

51. Summary
MVs are a very powerful feature that allows you to aggregate information for improving performance and also for replicating data between database environments.
MVs are a feature rich utility and as a DBA and developer you should be aware of this tool and how to implement and manage these objects.