Materialized Views

Materialized Views

        Materialized views are query results that have been stored or "materialized" in advance as schema objects. The FROM clause of the query can name tables, views, and materialized views. Collectively these objects are called master tables (a replication term) or detail tables (a data warehousing term).

        Materialized views are used to summarize, compute, replicate, and distribute data. They are suitable in various computing environments, such as the following:
        ■In data warehouses, you can use materialized views to compute and store data generated from aggregate functions such as sums and averages.

        A summary is an aggregate view that reduces query time by precalculating joins and aggregation operations and storing the results in a table. Materialized views are equivalent to summaries (see "Data Warehouse Architecture (Basic)" on page 17-17). You can also use materialized views to compute joins with or without aggregations. If compatibility is set to Oracle9i or higher, then materialized views are usable for queries that include filter selections.

        ■In materialized view replication, the view contains a complete or partial copy of a table from a single point in time. Materialized views replicate data at distributed sites and synchronize updates performed at several sites. This form of replication is suitable for environments such as field sales when databases are not always connected to the network.
        ■In mobile computing environments, you can use materialized views to download a data subset from central servers to mobile clients, with periodic refreshes from the central servers and propagation of updates by clients to the central servers.
        In a replication environment, a materialized view shares data with a table in a different database, called a master database. The table associated with the materialized view at the master site is the master table. Figure 4–7 illustrates a materialized view in one database based on a master table in another database. Updates to the master table replicate to the materialized view database.

Characteristics of Materialized Views

        Materialized views share some characteristics of nonmaterialized views and indexes. Materialized views are similar to indexes in the following ways:
        ■They contain actual data and consume storage space.
        ■They can be refreshed when the data in their master tables changes.

        ■They can improve performance of SQL execution when used for query rewrite operations.
        ■Their existence is transparent to SQL applications and users.

        A materialized view is similar to a nonmaterialized view because it represents data in other tables and views. Unlike indexes, users can query materialized views directly using SELECT statements. Depending on the types of refresh that are required, the views can also be updated with DML statements.
        The following example creates and populates a materialized aggregate view based on three master tables in the sh sample schema:

CREATE MATERIALIZED VIEW sales_mv ASSELECT t.calendar_year, p.prod_id, SUM(s.amount_sold) AS sum_salesFROM times t, products p, sales sWHERE t.time_id = s.time_idAND p.prod_id = s.prod_idGROUP BY t.calendar_year, p.prod_id;

        The following example drops table sales, which is a master table for sales_mv, and then queries sales_mv. The query selects data because the rows are stored (materialized) separately from the data in the master tables.

SQL> DROP TABLE sales;Table dropped.SQL> SELECT * FROM sales_mv WHERE ROWNUM < 4;CALENDAR_YEAR PROD_ID SUM_SALES------------- ---------- ----------1998 13 936197.531998 26 567533.831998 27 107968.24

        A materialized view can be partitioned. You can define a materialized view on a partitioned table and one or more indexes on the materialized view.

Refresh Methods for Materialized Views

        The database maintains data in materialized views by refreshing them after changes to their master tables. The refresh method can be incremental, known as fast refresh, or a complete refresh.
        A complete refresh occurs when the materialized view is initially defined as BUILD IMMEDIATE, unless the materialized view references a prebuilt table. The refresh involves executing the query that defines the materialized view. This process can be slow, especially if the database must read and process huge amounts of data.
        A fast refresh eliminates the need to rebuild materialized views from scratch. Thus, processing only the changes can result in a very fast refresh time. Materialized views can be refreshed either on demand or at regular time intervals. Alternatively, materialized views in the same database as their master tables can be refreshed whenever a transaction commits its changes to the master tables.

        For materialized views that use the fast refresh method, a materialized view log or direct loader log keeps a record of changes to the master tables. A materialized viewlog is a schema object that records changes to master table data so that a materialized view defined on the master table can be refreshed incrementally. Each materialized view log is associated with a single master table. The materialized view log resides in the same database and schema as its master table.

Query Rewrite

        Query rewrite is an optimization technique that transforms a user request written in terms of master tables into a semantically equivalent request that includes materialized views. When base tables contain large amounts of data, computing an aggregate or join is expensive and time-consuming. Because materialized views contain precomputed aggregates and joins, query rewrite can quickly answer queries using materialized views.
        The optimizer query transformer transparently rewrites the request to use the materialized view, requiring no user intervention and no reference to the materialized view in the SQL statement. Because query rewrite is transparent, materialized views can be added or dropped without invalidating the SQL in the application code.
        In general, rewriting queries to use materialized views rather than detail tables improves response time. Figure 4–8 shows the database generating an execution plan for the original and rewritten query and choosing the lowest-cost plan.

查询重写相关资料