General Use of Oracle Materialized Views

http://blog.csdn.net/tegwy/article/details/8935058Copyright

statement: This article is an original article by the blogger and may not be reproduced without the blogger's permission.
There is a project that uses a materialized view because there are more query summaries and considering the speed. Simply organize what you use.

First look at the simple creation statement:
create materialized view mv_materialized_test refresh force on demand start with sysdate next
to_date(concat(to_char( sysdate+1,'dd-mm-yyyy'),'10:25:00'),'dd-mm -yyyy hh24:mi:ss') as
select * from user_info; --This materialized view is refreshed at 10:25 every day. The

materialized view is also a view. Oracle's materialized views are database objects that contain the results of a query, which are local copies of remote data, or are used to generate summary tables based on table sums. Materialized views store data based on remote tables and can also be called snapshots.
Materialized views can query tables, views, and other materialized views.

Features:
(1) A materialized view is a physical table in a sense (and not just a physical table), which is confirmed by being queried by user_tables;
(2) A materialized view is also a segment ( segment), so it has its own physical storage attributes;
(3) The materialized view will occupy the disk space of the database, which can be proved from the query result of user_segment;
Create statement: create materialized view mv_name as select * from table_name
Because the materialized view exists physically, it can create an index.

Generate data when creating:
There are two types: build immediate and build deferred.
Build immediate generates data when the materialized view is created.
The build deferred does not generate data when it is created, and generates data later as needed.
If not specified, it defaults to build immediate.

Refresh mode:
The materialized view has two refresh modes:
whether the refresh mode is on demand or on commit when it is created.
on demand As the name implies, the refresh (REFRESH) is performed only when the materialized view "needs" to be refreshed, that is, the materialized view is updated to ensure consistency with the data of the base table;
on commit The commit is triggered, once the base table has a commit, That is, if the transaction is committed, it will be refreshed immediately, and the materialized view will be updated immediately, so that the data is consistent with the base table. Generally, this method will be slower when operating the base table.
Not specified when creating a materialized view, Oracle creates it in on demand mode.

The above is the refresh mode. There are three refresh methods for how to refresh:

Complete refresh (COMPLETE): All records in the table will be deleted (if it is a single table refresh, the TRUNCATE method may be used), and then according to the materialization The definition of the query statement in the view regenerates the materialized view.
Fast refresh (FAST): Using the incremental refresh mechanism, only all operations performed on the base table since the last refresh are refreshed to the materialized view. FAST must create a view log based on the primary table. For the incremental refresh option, the materialized view does not work if there is an analytic function in the subquery.
FORCE mode: This is the default data refresh mode. Oracle will automatically determine whether the fast refresh conditions are met, and if so, perform a fast refresh, otherwise, perform a full refresh.

About fast refresh: The fast refresh mechanism of Oracle materialized view is done through the materialized view log. Oracle can also support the rapid refresh of multiple materialized views through a materialized view log. The materialized view log can be established as ROWID or PRIMARY KEY according to the needs of fast refresh of different materialized views. You can also choose whether to include SEQUENCE, INCLUDING NEW VALUES, and a list of specified columns.

Query rewrite (QueryRewrite):
including enable query rewrite and disable query rewrite.
Indicates whether the created materialized view supports query rewriting. Query rewriting means that when the base table of the materialized view is queried, oracle will automatically determine whether the result can be obtained by querying the materialized view. read data in.
Defaults to disable query rewrite.

Syntax:
create materialized view view_name
refresh [fast|complete|force]
[
on [commit|demand] |
start with (start_time) next (next_time)
]
AS subquery;

specific

operations Permissions required to create a materialized view:
grant create materialized view to user_name; create a materialized view log on

the source table:
create materialized view log on test_table 
tablespace test_space -- log space 
with primary key; -- specify the primary key type

Create a MATERIALIZED VIEW on the target database:
create materialized view mv_materialized_test refresh force on demand start with sysdate next
to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),'10:25:00'),'dd -mm-yyyy hh24:mi:ss') as
select * from user_info; --This materialized view is refreshed at 10:25 every day

Modify the refresh time:
alter materialized view mv_materialized_test refresh force on demand start with sysdate
next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 23:00:00'),'dd-mm-yyyy hh24:mi:ss');
or
alter materialized view mv_materialized_test refresh force on demand start with sysdate
next trunc(sysdate,'dd')+1+1/24; -- refresh at 1 o'clock every day

Create index:
create index IDX_MMT_IU_TEST
on mv_materialized_test(ID, UNAME) 
tablespace test_space;

delete materialized view and log:
drop materialized view log on test_table; --delete materialized view log:
drop materialized view mv_materialized_test; --delete materialized view