Oracle manifested View

1, reduce the burden of the network: through the MV data from a database distributed to a number of different databases, through multiple database access to alleviate the network burden on a single database.  2, build distribution environment: By distributing data from a central database to multiple node databases, the purpose of distributing data is achieved.  3, replicating subsets of data: MV can be filtered at row-level/column-level so that you can replicate the part of the data you need. Create materialized View [view_name]      {tablespace (table space name)}           &NBSP ;  --Save table Space       {build [deferred| IMMEDIATE (default)]}--Deferred refresh or immediate refresh  refresh [Fast|complete|force] [ on [Commit|demand] | start with ( Start_time) Next (next_time)  ] as {create materialized view with query statement}   related parameter description:  1, build clause: Define how to create, Includes build IMMEDIATE and build DEFERRED two  build IMMEDIATE generate data when creating a solid view, default build IMMEDIATE  build DEFERRED No data is generated at the time of creation, and later, as needed, in the Generate Data   2, refresh clause: Define data Synchronization refresh, when a DML operation occurs on the base table, when the manifested view is synchronized with the base table, syntax:  [ Refresh [Fast | complete | force]          [on demand | commit]       &N Bsp  [start with date]          [next date]     &nbsp    [with {PRIMARY key | Rowid}] ]  fast uses an incremental refresh to refresh only the modifications made since the last refresh, if the refresh FAST clause is specified, The materialized view log should be created for the main table, and if you do not create a mview log, you will get an error   Note: For incremental refresh options, materialized views do not work if there are analytic functions in the subquery.   complete completely refreshes the entire materialized view   force (default) When Oracle refreshes, it will determine if it can be quickly refreshed, or if it can be fast, otherwise, in the way of complete, The force option is the default option   on DEMAND (default) materialized views are refreshed when required by the user and can be manually passed through the Dbms_mview. Refresh, etc., or refresh by job timing  on Commit the entity view refreshes while the DML operation of the base table is committed   start with the first refresh time  next Refresh Interval  with PRIMARY key (default) generates a primary key manifested view, which means that the manifested view is based on the primary key of the table, not the ROWID (corresponding to the ROWID clause). In order to generate the PRIMARY key clause, you should define a primary key on the table, or you should use a ROWID-based, solid view. The primary key manifested view allows for the identification of manifested view charts without affecting the availability of an incremental refresh of the manifested views  with ROWID has only one single primary table and cannot include any of the following:   distinct  aggregate function   Group by   subquery   Connection   SET operation   3, query rewrite clause, define query rewrite   include enable query rewrite and disable QUERY rewrite two kinds. Indicates whether the created entity view supports query rewriting, respectively. Query rewriting means that when querying the base table of a manifested view, Oracle automatically determines whether the results can be obtained by querying the manifested view and, if so, avoids aggregation or join operations and reads the data directly from the computed,  enable QUERY REWRITESupport for query rewriting  disable query REWRITE does not support querying overrides, the default DISABLE query rewrite   Note: If you need a quick refresh, you need to establish a solid view log. The manifested view log can be built as a ROWID or primary key type, depending on the need for a fast refresh of the different manifested views. You can also choose whether to include sequence, including NEW values, and a list of specified columns.    materialized views can be partitioned. and partition-based materialized views can support partition change tracking (PCT). Materialized views with this feature can still be quickly refreshed when the base table is partitioned for maintenance operations.    Create a solid view of a multi-table association:  The manifested view contains multiple table associations, but does not contain aggregation operations, the entity view that contains only the table associations also supports flushing in both cases:  on COMMIT and on DEMAND. On commit, the manifested view is refreshed when the base table has a DML operation and commits a commit.  oracle does not allow the presence of self-jions in a manifested view.   If the specified refresh mode is refreshing fast, Oracle performs additional checks to determine that fast refresh can be performed. These additional checks include:  1 each base table must be created under the corresponding materialized view log 2 each base table rowID must appear in the SELECT statement of the manifested view  3 if there is an outer join, where Clauses cannot have any selections. Also, all associations must be connected with and with a "=" operator.  4 if an outer join exists, the uniqueness constraint must exist in the related column of the inner table that is being joined.

Oracle manifested View