1. Refreshing Materialized Views

2. Oracle Database 10g: Implement and Administer a Data Warehouse 11-2
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
Oracle Database 10g: Implement and Administer a Data Warehouse

3. Oracle Database 10g: Implement and Administer a Data Warehouse 11-3
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 Options
When you define a materialized view, you can specify how you want the materialized view to be refreshed from the detail tables by selecting one of the following options:
COMPLETE: The COMPLETE refresh mechanism deletes or truncates the materialized view and then recomputes the contents by re-executing the materialized view query against the detail tables.
FAST: This option refreshes by incrementally adding the new data that has been inserted or updated into the tables. The new data is obtained from:
The direct-path log: Direct-path load supports materialized views by recording the row ID ranges of loaded data in the ALL_SUMDELTA view. The refresh “understands” what has been added to the detail table by use of this view, and the refresh can be fast with the use of the row IDs. A manual refresh must be executed right after the load to avoid the invalidation of the log’s content.
Oracle Database 10g: Implement and Administer a Data Warehouse

4. Oracle Database 10g: Implement and Administer a Data Warehouse 11-4
Refresh Options (continued)
The materialized view log created on the master tables: This log is a table created by the CREATE MATERIALIZED VIEW LOG command. When DML changes are made to the master table data, the Oracle server stores rows describing those changes in the materialized view log and then uses that log to refresh materialized views based on the master table. If you specify REFRESH FAST for a materialized view, you must have created a materialized view log for the underlying tables, or the command will fail.
Partition Change Tracking (PCT) refresh: When partition maintenance operations occur on a partitioned detail table, the Oracle server uses a specialized form of fast refresh called Partition Change Tracking. It automatically identifies the stale portion of the materialized view and re-computes the stale rows without having to refresh the entire materialized view.
FORCE: This mechanism applies FAST refresh if possible; otherwise, it applies COMPLETE refresh.
NEVER: The NEVER refresh mechanism prevents the materialized view from being refreshed with any Oracle Database refresh mechanism or procedure.
Full Notes Page
Oracle Database 10g: Implement and Administer a Data Warehouse

5. Oracle Database 10g: Implement and Administer a Data Warehouse 11-5
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 Modes
You can specify the following refresh execution modes:
ON DEMAND (the default): Refresh occurs at user demand by using the DBMS_MVIEW package. This package provides several procedures and functions to manage materialized views, including the REFRESH, REFRESH_DEPENDENT, and REFRESH_ALL_MVIEWS procedures.
ON COMMIT: Refresh occurs automatically when a transaction that modified one of the detail tables of the materialized view commits. This can be specified as long as the materialized view is fast refreshable. The ON COMMIT privilege is necessary to use this mode. If a materialized view fails during refresh at commit time, the user must explicitly invoke the refresh procedure by using the DBMS_MVIEW package after addressing the errors specified in the trace files. Until this is done, the view is no longer refreshed automatically at commit time. The time required to complete the commit is slightly longer because the materialized view has to be updated with the changes.
Oracle Database 10g: Implement and Administer a Data Warehouse

6. 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 …
Refresh at Scheduled Time
You can create your materialized view to be refreshed at a scheduled time. For example, it can be refreshed every Monday at 9:00 a.m. by using the START WITH and NEXT clauses. In order for such refreshes to occur, the instance must initiate job processes with the JOB_QUEUE_PROCESSES parameter.
Note: If you specify ON COMMIT or ON DEMAND, you cannot also specify START WITH or NEXT.
The first example in the slide does not include a START WITH parameter, so Oracle Database determines the first automatic refresh time by evaluating the NEXT value using the current SYSDATE.
The second example illustrates how you can instruct Oracle Database to automatically refresh the materialized view tomorrow at 11:00 a.m. and subsequently every Monday at 3:00 p.m.
Oracle Database 10g: Implement and Administer a Data Warehouse

7. 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
Manual Refresh Using DBMS_MVIEW
You can control the time when refresh of the materialized views occurs by specifying ON DEMAND refreshes. In this case, the materialized view can be refreshed only by calling one of the procedures in the DBMS_MVIEW package:
DBMS_MVIEW.REFRESH: Refresh one or more materialized views
DBMS_MVIEW.REFRESH_ALL_MVIEWS: Refresh all materialized views
DBMS_MVIEW.REFRESH_DEPENDENT: Refresh all table-based materialized views that depend on a specified detail table or list of detail tables
Job queues can be used to refresh multiple materialized views in parallel. If queues are not available, fast refresh will sequentially refresh each view in the foreground process. The order in which the materialized views are refreshed cannot be guaranteed. To make queues available, you must set the JOB_QUEUE_PROCESSES parameter to a value equal to or greater than 1. This parameter defines the number of background job queue processes (CJQn) and determines how many materialized views can be refreshed concurrently. This parameter is effective only when the atomic_refresh parameter of the DBMS_MVIEW procedure is set to FALSE. Additional information is provided on the next few pages.
Oracle Database 10g: Implement and Administer a Data Warehouse

8. Oracle Database 10g: Implement and Administer a Data Warehouse 11-8
Manual Refresh Using DBMS_MVIEW (continued)
Note: If the process that is executing DBMS_MVIEW.REFRESH is interrupted or the instance is shut down, any refresh jobs that were executing in job queue processes are requeued and continue running. To remove these jobs, use the DBMS_JOB.REMOVE procedure.
Full Notes Page
Oracle Database 10g: Implement and Administer a Data Warehouse

9. Refresh Specific Materialized Views with REFRESH
exec DBMS_MVIEW.REFRESH(-
'MV1,MV2','FC','',FALSE,TRUE,0,0,0,FALSE);
Refresh each in a separate transaction
Continue when there are errors
Do not push changes
Refresh method for each
Refresh Specific Materialized Views with REFRESH
Use the DBMS_MVIEW.REFRESH procedure to refresh one or more materialized views. The parameters are as follows:
LIST: The comma-delimited list of materialized views to refresh. Note that if the materialized view names are not prefixed by the schema name, it is assumed that they are owned by the schema from where the execution is triggered.
METHOD: The refresh method (refresh code) to be used: F-Fast, P-Fast_PCT, ?-Force, C-Complete. If the refresh method is not specified, the default refresh method, as specified in the materialized view definition, is used.
ROLLBACK_SEG: The rollback segment to use
PUSH_DEFERRED_RPC: Used by updateable materialized views only. Set this parameter to TRUE if you want to push changes from the materialized view to its associated master tables or master materialized views before refreshing the materialized view. In a data warehouse environment, set this parameter to FALSE.
Note: The parameter list continues on the next page.
List of materialized views
Oracle Database 10g: Implement and Administer a Data Warehouse

10. Oracle Database 10g: Implement and Administer a Data Warehouse 11-10
Refresh Specific Materialized Views with REFRESH (continued)
REFRESH_AFTER_ERRORS: If set to FALSE, the default, then refresh will stop after it encounters the first error, and any remaining materialized views in the list will not be refreshed. The error is displayed on the screen. The alert log for the instance as well as CJQn trace files, give details of refresh errors, only if job queue processes are used. If set to TRUE, while errors can be logged in the alert log and trace files, but not on screen, each materialized view in the list is tried for refresh. Set ATOMIC_REFRESH to FALSE when setting this parameter to TRUE. Otherwise, only the first error to occur is displayed on the screen, and the other materialized views in the list are not refreshed.
PURGE_OPTION, PARALLELISM, and HEAP_SIZE: Used by the replication process. For data warehouse refresh operations, set them to 0,0,0.
ATOMIC_REFRESH: If set to TRUE, then all refreshes are always done in one transaction by the foreground session. If set to FALSE, then the refresh of each specified materialized view is done in a separate transaction by the foreground session, or by CJQn processes if the value of the job_queue_processes parameter is equal or greater than 1. To refresh multiple materialized views in parallel, the number of job queue processes must be set to a value greater than 1.
The example on the previous page performs a fast refresh on the MV1 materialized view and a complete refresh on the MV2 materialized view. To provide different refresh methods for each materialized view, specify multiple method codes in the same order as the list of materialized views (without commas). The example assumes that if MV1 cannot be refreshed, MV2 should be tried. Also, each refresh is done in its own transaction.
Full Notes Page
Oracle Database 10g: Implement and Administer a Data Warehouse

11. Refresh All Materialized Views with REFRESH_ALL_MVIEWS
VARIABLE fail NUMBER;
exec DBMS_MVIEW.REFRESH_ALL_MVIEWS(-
:fail, 'C','', TRUE, FALSE);
Refresh each in a separate transaction
Continue when there are errors
Refresh method for each
Refresh All Materialized Views with REFRESH_ALL_MVIEWS
An alternative to specifying the materialized views to refresh is to use the DBMS_MVIEW.REFRESH_ALL_MVIEWS procedure. This procedure refreshes all existing materialized views. If any of the materialized views fails to refresh, then the number of failures is reported.
The first parameter, fail as specified in the example, is a number variable returning the number of failed refreshes. For the other parameters, refer to the detailed information about the REFRESH procedure described previously in the lesson.
The example shown in the slide refreshes all materialized views listed in DBA_MVIEWS with a complete refresh executed for each of them. Whenever a refresh is not possible, the procedure continues with the next materialized view, until all materialized views have been refreshed. In the example, each refresh is performed in its own transaction.
Note: The order in which the materialized views are refreshed cannot be determined in advance.
Returns number of failed refreshes
Oracle Database 10g: Implement and Administer a Data Warehouse

12. 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);
Continue when there are errors
Refresh Dependent Materialized Views with REFRESH_DEPENDENT
The DBMS_MVIEW.REFRESH_DEPENDENT procedure refreshes only those materialized views that depend directly on specific tables, or other materialized views. The example performs:
A complete refresh on all materialized views that reference the CUSTOMERS table
A fast refresh on all materialized views that reference the SALES table
Note also that the example does not stop as soon as one refresh gives an error. Also, each refresh uses its own transaction. For the other parameters, refer to the detailed information on the REFRESH procedure described previously in the lesson.
Note: If objects in the list are not prefixed by a schema name, it is assumed that the object is owned by the schema from where the execution is triggered.
Refresh method for each
Refresh each in a separate transaction
List of materialized views
Oracle Database 10g: Implement and Administer a Data Warehouse

13. 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
Finding Dependent Materialized Views
To obtain the list of materialized views that are directly dependent on a given object (table or materialized view), use the DBMS_MVIEW.GET_MV_DEPENDENCIES procedure. You can use this procedure to determine the dependent materialized views or to determine the refresh order for nested materialized views.
The input to the DBMS_MVIEW.GET_MV_DEPENDENCIES procedure is the name or names of the materialized views or tables. The output is a comma-separated list of the materialized views that are defined on the input objects.
In the slide example, the procedure is used to find all materialized views depending on the CUSTOMERS and SALES tables.
List of materialized views
Oracle Database 10g: Implement and Administer a Data Warehouse

14. When Does a Complete Refresh Occur?
Initial build of the materialized view (BUILD IMMEDIATE)
First refresh for BUILD DEFERRED materialized views
Manual request
When Does a Complete Refresh Occur?
A complete refresh occurs when the materialized view is initially defined as BUILD IMMEDIATE, unless the materialized view references a prebuilt table. For materialized views defined with BUILD DEFERRED, a complete refresh must be requested before it can be used for the first time. A complete refresh may be requested at any time during the life of any materialized view. The refresh involves reading the underlying tables to compute the results for the materialized view. This can be a very time-consuming process, especially if there are huge amounts of data to be read and processed. Therefore, you should always consider the time required to process a complete refresh before requesting it. However, there are cases when the only refresh method available for an already built materialized view is complete refresh because the materialized view does not satisfy the conditions that are specified in the following section for a fast refresh.
Oracle Database 10g: Implement and Administer a Data Warehouse

15. 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
Conditions That Effect Possibility of Fast Refresh
The remainder of this lesson is primarily concerned with fast refreshes. There are many conditions that allow the Oracle server to perform fast refreshes for a particular materialized view.
One requirement for fast refresh is to have a materialized view log created on the tables underlying the materialized view.
Also, the materialized view detail query is very important. In certain cases, its SELECT list must contain specific columns in order for a fast refresh to be possible. For example, AVG requires COUNT.
The fast refresh capability also relies on the various types of modifications that are made to master tables, as well as the sequence of these modifications. Sometimes fast refresh also depends on which detail table is modified. For example, if a materialized view is based on two different tables and only the first one has a materialized view log, and if only the first table is modified, then the entire materialized view can still be fast refreshed. Use DBMS_MVIEW.EXPLAIN_MVIEW to determine whether a materialized view is eligible for fast refresh.
Oracle Database 10g: Implement and Administer a Data Warehouse

16. 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.
Explain Materialized View
You can use the DBMS_MVIEW.EXPLAIN_MVIEW procedure to determine what is possible with a given materialized view or potential materialized view. This procedure provides the following information:
Is this materialized view fast refreshable?
What type of query rewrite can be performed with this materialized view?
Invoke the DBMS_MVIEW.EXPLAIN_MVIEW procedure with the schema and materialized view name for an existing materialized view. Alternatively, you can specify the SELECT statement for a potential materialized view. The materialized view or potential materialized view is then analyzed and the results are written either into a table called MV_CAPABILITIES_TABLE, which is the default, or to a VARRAY of type ExplainMVArrayType called MSG_ARRAY.
Note: Execute the $ORACLE_HOME/rdbms/admin/utlxmv.sql script to create the MV_CAPABILITIES_TABLE table in the current schema before calling EXPLAIN_MVIEW.
Oracle Database 10g: Implement and Administer a Data Warehouse

17. Using DBMS_MVIEW.EXPLAIN_MVIEW
EXEC dbms_mview.explain_mview('sales_sum', '123');
SELECT capability_name, possible, related_text,
msgtxt
FROM mv_capabilities_table
WHERE 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
Using DBMS_MVIEW.EXPLAIN_MVIEW
In this example, an existing materialized view called SALES_SUM in the SH schema is analyzed. An ID is assigned for this analysis so that it can be retrieved afterward in the MV_CAPABILITIES_TABLE table. The SEQ column is used in an ORDER BY clause so the rows will display in a logical order.
If a capability is not possible, N appears in the P column and an explanation in the MSGTXT column. If a capability is not possible for more than one reason, a row is displayed for each reason.
Because the materialized view log of the TIMES table does not have new values, the Oracle server is unable to fast refresh this materialized view.
Note: For more information about the possible values of MV_CAPABILITIES_TABLE columns, refer to the Oracle Database Data Warehousing Guide.
Oracle Database 10g: Implement and Administer a Data Warehouse

18. 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.
Materialized View Logs: General Concepts
Materialized view logs are required if you want to use fast refresh, with the exception of PCT refresh. If a detail table supports PCT for a materialized view, the materialized view log on that detail table is not required in order to do fast refresh on that materialized view. As a general rule, though, you should create materialized view logs if you want to use fast refresh. Materialized view logs are defined using a CREATE MATERIALIZED VIEW LOG statement on the base table that is to be changed.
For fast refresh of materialized views, the definition of the materialized view logs must normally specify the ROWID clause. In addition, for aggregate materialized views, it must also contain every column in the table referenced in the materialized view, the INCLUDING NEW VALUES clause, and the SEQUENCE clause.
Note: Specify SEQUENCE to indicate that a sequence value providing additional ordering information should be recorded in the materialized view log. Sequence numbers are internally necessary to support fast refresh after some update scenarios.
When using nested materialized views, all detail objects (materialized views or tables) on which the materialized view is defined must have a materialized view log. These objects are treated like normal tables.
Oracle Database 10g: Implement and Administer a Data Warehouse

19. Creating a Materialized View Log
CREATE MATERIALIZED VIEW LOG ON sh.sales
TABLESPACE users
NOLOGGING
PARALLEL
WITH SEQUENCE, ROWID
(quantity_sold,amount_sold)
INCLUDING NEW VALUES;
Creating a Materialized View Log
When creating a materialized view log, the Oracle server creates an internal table that stores the modifications performed to the corresponding table. You can specify various physical attributes such as the tablespace in which to store the materialized view log, as well as the storage attributes when creating a materialized view log. You can also partition a materialized view log by using the same syntax as the one used for tables. Note that it is possible to specify the LOGGING attribute as well as the PARALLEL clause.
After physical attributes are specified, you need to specify what is going to be registered into the materialized view log. In the slide example, ROWIDs of the SALES table are recorded during sales modifications. The sequence number is also recorded for fast refresh of joins and aggregate materialized views. It is also possible to specify additional columns including or excluding their new values. This is necessary for certain fast refresh cases.
Note: The materialized view logs are automatically maintained by Oracle Database. The materialized view logs are purged when they are no longer needed.
Oracle Database 10g: Implement and Administer a Data Warehouse

20. 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.
Restrictions for Fast-Refreshable Materialized Views
The detail query of the materialized view is restricted as follows:
Must not contain references to non-repeating expressions such as SYSDATE and ROWNUM
Must not contain references to RAW or LONG RAW data types
Subqueries in the WHERE clause are generally not supported for fast refresh except in the particular case of data subsetting used mainly for replication purposes. For more information about these types of materialized views, refer to the Oracle Database Advanced Replication manual.
For detailed information about restrictions for specific types of materialized views, refer to the Oracle Database Data Warehousing Guide.
Oracle Database 10g: Implement and Administer a Data Warehouse

21. 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.
Indexes and Fast-Refreshable Materialized Views
Whenever a materialized view is fast refreshable, the Oracle server may create a default index used during a fast refresh to enhance the performance of this operation.
This index is created automatically when the materialized view is a joins and aggregate materialized view. When you create a materialized view, you can specify the USING INDEX clause in the CREATE MATERIALIZED VIEW statement. This enables you to specify certain storage characteristics for the default index. It is also possible to use the USING NO INDEX clause in order to avoid or postpone the default index creation. In this case, you should create it manually when appropriate. If you decide to create this index after materialized view creation, you should create the index as follows:
CREATE UNIQUE INDEX index_name ON mv_name
(SYS_OP_MAP_NONNULL (key1), … , SYS_OP_MAP_NONNULL(keyn)); where keyn is a materialized view key, an expression that appears in the GROUP BY list of the detail query.
An index is never automatically created for materialized join views. To speed up refresh of these types of materialized views, create indexes on the columns of the materialized view that store the row IDs of the detail tables.
Oracle Database 10g: Implement and Administer a Data Warehouse

22. 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.
Specifying REFRESH FORCE
If you attempt to create a materialized view where one of the detail tables does not meet the fast refresh restrictions, you can create the materialized view with REFRESH FORCE to take advantage of times when modifications are limited to detail tables that meet the fast refresh criteria.
The FAST_REFRESHABLE column in DBA_MVIEWS tells you whether or not the materialized view is eligible for fast refresh. The Oracle server calculates this value statically, based solely on the materialized view definition query. The FAST_REFRESHABLE column contains the following values:
NO: The materialized view is not fast refreshable.
DIRLOAD: Fast refresh is supported only for direct loads on the master table.
DML: Fast refresh is supported only for DML operations on the master table.
DIRLOAD_DML: Fast refresh is supported for both direct loads and DML operations.
DIRLOAD_LIMITEDDML: Fast refresh is supported for direct loads and a DML subset.
Oracle Database 10g: Implement and Administer a Data Warehouse

23. Oracle Database 10g: Implement and Administer a Data Warehouse 11-23
Specifying REFRESH FORCE (continued)
In order to tell whether or not the last refresh operation was a fast or a complete refresh, query the LAST_REFRESH_TYPE column of DBA_MVIEWS. This column contains the following values:
COMPLETE: The most recent refresh was complete.
FAST or FAST_PCT: The most recent refresh was fast (incremental).
NA: The materialized view has not yet been refreshed (for example, if it was created DEFERRED).
Note: Materialized view logs must be correctly defined on each detail table in case you want to fast refresh a dependent materialized view.
Full Notes Page
Oracle Database 10g: Implement and Administer a Data Warehouse

24. 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
Partition Change Tracking (PCT) Refresh
Partition Change Tracking (PCT) is a specialized form of fast refresh. It is automatically invoked when a fast refresh against the materialized view log is requested but not possible due to a partition maintenance operation on a materialized view’s detail table.
It is possible and advantageous to track freshness to a finer grain than in the entire materialized view. The ability to identify which rows in a materialized view are affected by a certain detail table partition is known as Partition Change Tracking (PCT). When one or more of the detail tables is partitioned, it may be possible to identify the specific rows in the materialized view that correspond to a modified detail partition. Those rows become stale when a partition is modified while all other rows remain fresh. PCT can be used to identify which materialized view rows correspond to a particular detail table partition. The Oracle server can fast refresh after partition maintenance operations on detail tables. For instance, if a detail table partition is truncated or dropped, the affected rows in the materialized view are identified and deleted. PCT is a mechanism to identify the stale portion of the materialized view, thereby allowing the Oracle server to recompute the stale rows regardless of the exact operation that caused the row to go stale. Note that this mechanism can also be used whenever fast refresh is not supported after certain sequences of DML operations on partitioned detail tables.
Note: In many cases, PCT refresh should perform better than a complete refresh.
Oracle Database 10g: Implement and Administer a Data Warehouse

25. 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
PCT Refresh Requirements
To support PCT refresh, a materialized view must satisfy the following requirements:
At least one of the referenced detail tables must be partitioned.
Partitioned tables must use range, composite, or list partitioning.
The partition key must consist of only a single column.
The materialized view must contain the partition key column of the detail table, a partition marker (DBMS_MVIEW.PMARKER function), a ROWID, or a join-dependent expression of one of its detail tables in its SELECT list. PCT requires sufficient information in the materialized view to be able to correlate each materialized view row back to its corresponding detail row in its source partitioned detail table.
If a GROUP BY clause is used, the partition key column or the partition marker must be present in the GROUP BY clause.
Data modifications can occur only on the partitioned detail table that conforms to the requirements mentioned above.
Partition Change Tracking is not supported for a materialized view that refers to views, remote tables, or outer joins.
Note: You can combine a partition key and a partition marker in the detail query. Partitioning of the materialized view itself has no bearing on this feature.
Oracle Database 10g: Implement and Administer a Data Warehouse

26. 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.
When Is PCT Refresh Used?
There may be cases where PCT refresh performs better than fast refresh; however, this is not always true. So, PCT refresh is invoked only if fast refresh is required but cannot be performed in the usual way. That is:
A fast refresh is required, and
A detail table is partitioned, and
PCT refresh is possible for the materialized view, and
A partition DDL operation has been performed against partitioned detail tables, and/or
Combinations of DML/ direct loads not handled by a fast refresh algorithm have occurred.
In Oracle Database 10g, you can force PCT-based fast refresh. The METHOD parameter of the refresh procedures accepts a value of P. This forces PCT refresh even if there have been only DMLs and no partition maintenance operation (PMOP) DDLs on the partitioned base tables. The refresh procedure returns an error if PCT refresh is not possible.
Note: The LAST_REFRESH_TYPE column of the DBA_MVIEWS view contains a value of FAST_PCT when such a refresh was done.
Oracle Database 10g: Implement and Administer a Data Warehouse

27. Partition Key or Partition Marker?
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?
Partition Change Tracking requires sufficient information in the materialized view to be able to correlate each materialized view row back to its corresponding detail row in the source partitioned detail table. This can be accomplished by including the detail table partition key columns in the SELECT list and, if GROUP BY is used, in the GROUP BY list, as described on the previous pages.
Depending on the desired level of aggregation and the distinct cardinalities of the partition key columns, this has the unfortunate effect of significantly increasing the cardinality of the materialized view. For example, assume that a popular metric is the revenue generated by a product during a given year. If the COSTS table is partitioned by TIME_ID, it is a required field in the SELECT clause and the GROUP BY clause of the materialized view. If 1,000 different products are sold each day, it would substantially increase the number of rows in the materialized view. In many cases, the advantages of PCT are offset by this restriction for highly aggregated materialized views.
Cardinality = #part_keys x distinct(prod_name)
Oracle Database 10g: Implement and Administer a Data Warehouse

28. Partition Key or Partition Marker?
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;
Partition Key or Partition Marker? (continued)
PCT requires sufficient information in the materialized view to be able to correlate each materialized view row back to its corresponding detail row in its source partitioned detail table. In general, this can be accomplished by including the detail table partition key columns in the SELECT list and, if GROUP BY is used, in the GROUP BY list. This has the unfortunate effect of significantly increasing the cardinality of the materialized view, depending on the desired level of aggregation and the distinct cardinalities of the partition key columns. In many cases, the advantages of PCT can be offset by this restriction for highly aggregated materialized views.
The DBMS_MVIEW.PMARKER function addresses this problem. It returns a partition identifier that uniquely identifies the partition for a specified row ID within a specified partition table. The DBMS_MVIEW.PMARKER function can be used instead of the partition key column in the SELECT and GROUP BY lists.
Cardinality = #partitions x distinct(prod_name)
Oracle Database 10g: Implement and Administer a Data Warehouse

29. Oracle Database 10g: Implement and Administer a Data Warehouse 11-29
PCT Using ROWID
CREATE MATERIALIZED VIEW pct_rowid_mv
(srid, prid, cid, pname)
BUILD IMMEDIATE
REFRESH FORCE
ENABLE QUERY REWRITE AS
SELECT s.rowid, p.rowid,
s.channel_id, p.prod_name
FROM sales s, products p
WHERE s.prod_id = p.prod_id;
PCT Using ROWID
The ROWID pseudocolumn contains table partition information and can be used as a PCT column. This feature is especially useful for materialized join views that contain ROWIDs in their defining query.
For example, the SALES base table is RANGE-partitioned. The materialized view example contains the ROWID of the SALES PCT table, and has PCT refresh capability.
Oracle Database 10g: Implement and Administer a Data Warehouse

30. Consider Fresh: Fastest Refresh Scenario1 2
Drop partition 3
ALTER MATERIALIZED VIEW CONSIDER FRESH
Consider Fresh: Fastest Refresh Scenario
A common warehouse scenario involving materialized views and partition operations is as follows:
The detail table is partitioned using a DATE column as the partition key.
The materialized view contains the partition key in both the SELECT list and the GROUP BY list.
The materialized view is partitioned on the same partition key as the detail table.
The partition in the detail table that contains the oldest data is exchanged or dropped.
The corresponding partition operation is performed against the materialized view.
Note that performing the operation described above is even faster than using a PCT refresh (if possible). At this point, the data contained by the materialized view corresponds exactly with its detail query. Unless you issue a CONSIDER FRESH statement on the materialized view, the Oracle server believes the materialized view to be stale. Moreover, the Oracle server may require a complete refresh in order to make the materialized view status fresh again.
Although this is primarily targeted at the partition scenario just described, it is of general value. For instance, it could be used to perform some manual DML actions to “patch” the detail tables and corresponding materialized views even if not partitioned.
Fact MV
Oracle Database 10g: Implement and Administer a Data Warehouse

31. 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
CONSIDER FRESH Refresh Implications
Note that CONSIDER FRESH declares that the contents of the materialized view are FRESH (in sync with the detail tables), although this may not be true.
After using CONSIDER FRESH, you can apply traditional fast refresh after DML and direct loads to the materialized view, but not PCT fast refresh. This is because if the detail table partition at one time contained data that is currently kept in aggregated form in the materialized view, PCT refresh, in attempting to resynchronize the materialized view with that partition, can delete historical data that you want to keep in the materialized view.
After using CONSIDER FRESH, the materialized view status is set to UNKNOWN. The only way to return the materialized view to FRESH status is with a complete refresh that will also remove the historical data, if any, from the materialized view.
Oracle Database 10g: Implement and Administer a Data Warehouse

32. 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.
General Tips for Materialized View Refresh
If the ATOMIC_REFRESH parameter is set to FALSE, refresh truncates the data instead of deleting it. This allows several materialized views to be refreshed in parallel if multiple CJQn processes are started.
Because materialized view data is redundant and can always be reconstructed from the detail tables, it may be preferable to disable logging on the materialized view. To disable logging and execute incremental refresh non-recoverably, use the ALTER MATERIALIZED VIEW ... NOLOGGING statement before refreshing.
After the refresh operations, consult the alert log and the trace files to verify that no errors have occurred.
Try to perform one type of change (direct-path INSERT or DML) and then refresh the materialized view. The Oracle server can perform significant optimizations if it detects that only one type of change has been done.
You should invoke the refresh after each table is loaded, rather than load all the tables and then perform the refresh.
For ON COMMIT refresh, if many updates are needed, try to group them all into one transaction because refresh is performed just once at commit time, rather than after each update. It may not be possible to isolate the DML statements, in which case it helps to keep the transactions short.
Oracle Database 10g: Implement and Administer a Data Warehouse

33. 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.
Refresh Tips for Nested Materialized Views
If any of the materialized views are defined as ON DEMAND refresh (irrespective of whether the refresh method is FAST, FORCE, or COMPLETE), you need to refresh them in the correct order (taking into account the dependencies between the materialized views), because the nested materialized view is refreshed independently of the current state of the other materialized views (whether fresh or not).
If all the materialized views are defined for ON COMMIT refresh, the Oracle server builds a partially ordered set of materialized views and refreshes them such that, after the successful completion of the refresh, all the materialized views are fresh.
Note: ON COMMIT refresh for nested materialized views containing joins with aggregates is currently not supported.
Oracle Database 10g: Implement and Administer a Data Warehouse

34. Oracle Database 10g: Implement and Administer a Data Warehouse 11-34
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
Oracle Database 10g: Implement and Administer a Data Warehouse

35. Oracle Database 10g: Implement and Administer a Data Warehouse 11-35
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
Oracle Database 10g: Implement and Administer a Data Warehouse