11 Copyright © 2005, Oracle. All rights reserved. Refreshing Materialized Views.

11Copyright © 2005, Oracle. All rights reserved.

Refreshing Materialized Views

11-2 Copyright © 2005, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to do the following:

• Describe the various refresh methods and modes

• Refresh materialized views

• Create fast-refreshable materialized views

• Explain why materialized views cannot be fast refreshable

• Create materialized view logs

• Describe the benefit of Partition Change Tracking

• Use parallel refreshes


Refresh Options

Refresh options specified when the materialized view is created:

• COMPLETE: Re-executes query

• FAST: Refresh is based on delta– Using materialized view logs– Using direct loader log: ALL_SUMDELTA– Using Partition Change Tracking refresh

• FORCE: FAST if possible, otherwise COMPLETE• NEVER


Refresh Modes

Refresh execution modes specified when the materialized view is created:

• ON DEMAND: Manual refresh using procedures in DBMS_MVIEW package (default)

• ON COMMIT: Refresh performed at transaction commit– Only possible for fast-refreshable materialized

views– ON COMMIT REFRESH object privilege needed– In case of failure, subsequent refreshes are manual


Refresh at Scheduled Time

Schedule refresh at materialized view creation time with START WITH and NEXT:

CREATE MATERIALIZED VIEW emp_data_mv …

REFRESH FAST NEXT sysdate + 7 …

CREATE MATERIALIZED VIEW cust_data_mv …

REFRESH START WITH ROUND(SYSDATE + 1) + 11/24

NEXT NEXT_DAY(TRUNC(SYSDATE),'MONDAY')+ 15/24

…


Manual Refresh Using DBMS_MVIEW

• For ON DEMAND refresh

• Three procedures in the DBMS_MVIEW package:– REFRESH– REFRESH_ALL_MVIEWS– REFRESH_DEPENDENT

• The refresh can be performed by:– Foreground session, if no job queue process is

started– One or multiple job queue processes, if

JOB_QUEUE_PROCESSES is set– Multiple refresh, which can be done in parallel


Refresh Specific Materialized Views with REFRESH

exec DBMS_MVIEW.REFRESH(-

'MV1,MV2','FC','',FALSE,TRUE,0,0,0,FALSE);

List of materialized views

Refresh method for each

Do not push changes

Continue when there are errors

Refresh each in a separate

transaction


Refresh All Materialized Views with REFRESH_ALL_MVIEWS

VARIABLE fail NUMBER;

exec DBMS_MVIEW.REFRESH_ALL_MVIEWS(-

:fail, 'C','', TRUE, FALSE);

Returns number of failed refreshes




transaction


Refresh Dependent Materialized Views with REFRESH_DEPENDENT

Refresh all materialized views directly depending on a list of detail tables or materialized views:

VARIABLE fail NUMBER;

exec DBMS_MVIEW.REFRESH_DEPENDENT(-

:fail,'CUSTOMERS,SALES','CF','',TRUE, FALSE);





transaction


Finding Dependent Materialized Views

• Find direct dependencies only.

• Can be used to determine the materialized view refresh order for nested materialized views

VARIABLE deplist VARCHAR2(500)

exec DBMS_MVIEW.GET_MV_DEPENDENCIES(-

'CUSTOMERS,SALES',:deplist);


Returns list of dependent

materialized views


When Does a Complete Refresh Occur?

• Initial build of the materialized view (BUILD IMMEDIATE)

• First refresh for BUILD DEFERRED materialized views

• Manual request


Conditions That Effect Possibility of Fast Refresh

• Existence of materialized view logs

• Materialized view’s detail query

• Types of modifications made to the detail tables

• Sequence of modifications made to the detail tables


Explain Materialized View

• DBMS_MVIEW.EXPLAIN_MVIEW accepts:– Materialized view name, or– SQL statement

• Advises what is possible for:– An existing materialized view– A potential materialized view before you create it

• Results are stored in MV_CAPABILITIES_TABLE (relational table) or in a VARRAY.

• utlxmv.sql must be executed as the current user to create MV_CAPABILITIES_TABLE.


Using DBMS_MVIEW.EXPLAIN_MVIEW

EXEC dbms_mview.explain_mview('sales_sum', '123');

SELECT capability_name, possible, related_text, msgtxtFROM mv_capabilities_tableWHERE statement_id = '123' ORDER BY seq;

CAPABILITY_NAME P REL_TEXT MSGTXT---------------- - -------- ---------------------…REFRESH_COMPLETE Y REFRESH_FAST N REFRESH_FAST_AFTER_INSERT N TIMES mv log must have new values…


Materialized View Logs: General Concepts

• Definition: Table that contains rows describing changes made to a detail table

• The logs are required if fast refresh is used.

• Log definition must include the WITH ROWID clause.

• For joins and aggregate materialized views to be fast-refreshable after INSERTs, logs must include:– Every column referenced in the materialized view– The INCLUDING NEW VALUES clause

• An INSERT, UPDATE, DELETE combination on multiple detail tables requires the log to include the SEQUENCE clause.

• SEQUENCE provides ordering information.


Creating a Materialized View Log

CREATE MATERIALIZED VIEW LOG ON sh.sales TABLESPACE usersNOLOGGINGPARALLELWITH SEQUENCE, ROWID (quantity_sold,amount_sold) INCLUDING NEW VALUES;


Restrictions for Fast-Refreshable Materialized Views

• General restrictions:– No non-repeating expressions– No references to RAW or LONG RAW data types– Support for subqueries in the WHERE clause limited

to data subsetting (WHERE EXISTS)

• Additional restrictions apply for specific types of materialized views.


Indexes and Fast-Refreshable Materialized Views

• Fast refresh joins and aggregate materialized view– The Oracle server automatically creates a unique

functional index on a materialized view’s keys for better fast refresh performance.

– Index expression: SYS_OP_MAP_NONNULL(keyn)– USING [NO] INDEX clause at creation time

• Fast refresh joins-only materialized view– No index is automatically created.– For better fast refresh performance, create an index

on row ID columns of the select list.


Specifying REFRESH FORCE

• Materialized view may be fast refreshable in some, but not all cases.– Joins-only materialized view without row IDs from

one of its detail tables can still be fast refreshed whenever updating only the other detail tables.

– Should be exception and should not be generalized

• Use REFRESH FORCE option during creation to ensure fast refresh whenever possible.

• Query DBA_MVIEWS.FAST_REFRESHABLE to determine whether the materialized view is eligible for fast refresh.


Partition Change Tracking (PCT) Refresh

• Fast refresh uses materialized view log or direct-loader log.

• Certain cases prevent using a materialized view log thus preventing general fast refresh.– Dropping of a detail table’s partition– Mixed DML when the materialized view uses the MIN

function

• Maintain staleness at partition level:– Only detected for partitioned detail tables– Only specific sections of the materialized view need

to be refreshed– Rows corresponding to impacted partitions only– Should be faster than a complete refresh


PCT Refresh Requirements

• One of the materialized view detail tables must be partitioned: RANGE, COMPOSITE, or LIST.

• Partition key must consist of a single column.

• SELECT and GROUP BY list must contain: partition key column, partition marker (DBMS_MVIEW.PMARKER), ROWID, or join-dependent expression of one of its detail tables.

• No reference to views or outer joins


When Is PCT Refresh Used?

• Fast refresh is requested, and

• A detail table is partitioned, and

• PCT refresh is possible for the materialized view, and

• One or both of the following two conditions have occurred on detail tables:– Partition DDL operations– Combinations of DML/direct-loads not handled by

fast refresh

• Requested using P parameter with refresh procedures

• FAST_PCT is indicated in LAST_REFRESH_TYPE.


Partition Key or Partition Marker?

Cardinality = #part_keys x distinct(prod_name)

CREATE MATERIALIZED VIEW cost_product_mv

(tid, pname, su, cu, cnt)

BUILD IMMEDIATE REFRESH FAST ON DEMAND

ENABLE QUERY REWRITE AS

SELECT time_id, prod_name, SUM(unit_cost),

COUNT(unit_cost), COUNT(*)

FROM sh.costs c, sh.products p

WHERE c.prod_id = p.prod_id

GROUP BY time_id, prod_name;


Partition Key or Partition Marker?

Cardinality = #partitions x distinct(prod_name)

CREATE MATERIALIZED VIEW cost_product_pm_mv

(pm, pname, su, cu, cnt)

BUILD IMMEDIATE REFRESH FAST ON DEMAND

ENABLE QUERY REWRITE AS

SELECT DBMS_MVIEW.PMARKER(c.rowid),

prod_name, SUM(unit_cost),

COUNT(unit_cost), COUNT(*)

FROM costs c, products p

WHERE c.prod_id = p.prod_id

GROUP BY DBMS_MVIEW.PMARKER(c.rowid),

prod_name;


PCT Using ROWID

CREATE MATERIALIZED VIEW pct_rowid_mv(srid, prid, cid, pname)BUILD IMMEDIATEREFRESH FORCEENABLE QUERY REWRITEASSELECT s.rowid, p.rowid, s.channel_id, p.prod_nameFROM sales s, products pWHERE s.prod_id = p.prod_id;


Consider Fresh: Fastest Refresh Scenario

Fact MV

Drop partition

ALTER MATERIALIZED VIEW CONSIDER FRESH

1 2

3


CONSIDER FRESH Refresh Implications

• STALENESS column of DBA_MVIEWS set to UNKNOWN until next complete refresh

• Until next complete refresh, PCT refresh no longer possible

• Fast refresh still possible


General Tips for Materialized View Refresh

• For complete refresh using DBMS_MVIEW interface, set ATOMIC_REFRESH to FALSE.

• Disable materialized view logging before refreshing (NOLOGGING).

• Always check alert.log and trace files after a refresh.

• Try to perform only one type of change before refreshing.

• Try to refresh directly after one table load.

• For ON COMMIT refresh, try to group DMLs in one single transaction or use short transactions.


Refresh Tips for Nested Materialized Views

• For ON DEMAND refresh:– You must refresh in the correct order.– Refresh is based on detail materialized views

independently of their STALENESS.

• For ON COMMIT refresh (simple joins or single-table aggregate):– Appropriate refresh order is automatically used.– In case of problem, you must refresh manually.


Summary

In this lesson, you should have learned how to:

• Create materialized views with different refresh methods and modes

• Use the DBMS_MVIEW package to refresh materialized views

• Use the DBMS_MVIEW package to explain materialized views

• Create materialized view logs

• Create materialized views supporting PCT


Practice 11: Overview

This practice covers the following topics:

• Using various refresh types: – COMPLETE– FAST– FAST_PCT

• Explaining materialized view refresh capabilities

• Creating materialized view logs

11 Copyright © 2005, Oracle. All rights reserved. Refreshing Materialized Views.

Documents

refresh refresh

dependent refresh

manual refresh

complete refresh

mviews refresh

demand refresh

multiple refresh

refresh mv1