Professional Documents
Culture Documents
A materialized view, or snapshot as they were previously known, is a table segment whose contents are periodically
refreshed based on a query, either against a local or remote table. Using materialized views against remote tables is the
simplest way to achieve replication of data between sites. The example code in this article assumes DB1 is the master
instance and DB2 is the materialized view site.
Basic Syntax
Check Privileges
Create Materialized View
Create Materialized View Logs
Refresh Materialized Views
Cleaning Up
Aggregations and Transformations
Considerations
Basic Syntax
The full syntax description for the CREATE MATERIALIZED VIEWcommand is available in the documentation. Here we will
only concern ourselves with the basics.
CREATE MATERIALIZED VIEW view-name
BUILD [IMMEDIATE | DEFERRED]
REFRESH [FAST | COMPLETE | FORCE ]
ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
[ON PREBUILT TABLE]
AS
SELECT ...;
The BUILD clause options are shown below.
IMMEDIATE : The materialized view is populated immediately.
DEFERRED : The materialized view is populated on the first requested refresh.
The following refresh types are available.
FAST : A fast refresh is attempted. If materialized view logs are not present against the source tables in advance, the
creation fails.
COMPLETE : The table segment supporting the materialized view is truncated and repopulated completely using the
associated query.
FORCE : A fast refresh is attempted. If one is not possible a complete refresh is performed.
A refresh can be triggered in one of two ways.
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.
The QUERY REWRITE clause tells the optimizer if the materialized view should be consider for query rewrite operations. An
example of the query rewrite functionality is shown below.
The ON PREBUILT TABLE clause tells the database to use an existing table segment, which must have the same name as
the materialized view and support the same column structure as the query.
Check Privileges
Check the user who will own the materialized views has the correct privileges. At minimum they will require the CREATE
MATERIALIZED VIEWprivilege. If they are creating materialized views using database links, you may want to grant
them CREATE DATABASE LINK privilege also.
CONNECT sys@db2
GRANT CREATE MATERIALIZED VIEW TO scott;
GRANT CREATE DATABASE LINK TO scott;
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
'SCOTT.MINUTE_REFRESH',
'',
SYSDATE,
'/*1:Mins*/ SYSDATE + 1/(60*24)',
FALSE,
FALSE,
0,
NULL,
TRUE,
TRUE,
NULL,
NULL,
NULL);
BEGIN
DBMS_REFRESH.add(
name => 'SCOTT.MINUTE_REFRESH',
list => 'SCOTT.EMP_MV',
lax => TRUE);
END;
/
A materialized view can be manually refreshed using the DBMS_MVIEWpackage.
EXEC DBMS_MVIEW.refresh('EMP_MV');
Rather than using a refresh group, you can schedule DBMS_MVIEW.REFRESHcalled using the Oracle Scheduler
Cleaning Up
To clean up we must remove all objects.
CONNECT scott/tiger@db2
DROP MATERIALIZED VIEW emp_mv;
DROP DATABASE LINK DB1.WORLD;
BEGIN
DBMS_REFRESH.destroy(name => 'SCOTT.MINUTE_REFRESH');
END;
/
CONNECT scott/tiger@db1
DROP MATERIALIZED VIEW LOG ON scott.emp;
|
0 | SELECT STATEMENT
|
|
3 |
21 |
3
(0)| 00:00:01 |
|
1 | MAT_VIEW REWRITE ACCESS FULL| EMP_AGGR_MV |
3 |
21 |
3
(0)| 00:00:01 |
--------------------------------------------------------------------------------------------
Considerations
Before using materialized views and materialized view logs, consider the following:
Populating a materialized view adds load to both servers involved. The source server is queried to capture the data,
which is inserted into the destination server. Be sure the additional load does not adversely affect your primary
system.
Although materialized view logs improve the performance of materialized view refreshes, they do increase the work
needed to perform DDL on the base table. Check the additional work does not adversely affect performance on the
primary system.
If regular refreshes are not performed, materialized view logs can grow very large, potentially reducing the
performance of their maintenance and blowing tablespace limits.
Depending on the Oracle version and the complexity of the associated query, fast refreshes may not be possible.
When using materialized views to improve performance of transformations and aggregations,
the QUERY_REWRITE_INTEGRITY andQUERY_REWRITE_ENABLED parameters must be set or the server will not be able
to automatically take advantages of query rewrites. These parameters may be set in the pfile or spfile file if they are
needed permanently. Later releases have them enabled by default.
For more information see:
CREATE MATERIALIZED VIEW
CREATE MATERIALIZED VIEW LOG
DBMS_REFRESH
DBMS_MVIEW
Hope this helps. Regards Tim...