CHAPTER 19 • ORACLE8i DATA WAREHOUSING FEATURES 878 Here are some examples of altering Mviews: ALTER MATERIALIZED VIEW mv_emp_date_agg PCTFREE 10 PCTUSED 60 STORAGE (NEXT 100k); ALTER MATERIALIZED VIEW mv_emp_date_agg ADD PARTITION p5 VALUES LESS THAN (‘2003’) TABLESPACE data_2002; ALTER MATERIALIZED VIEW mv_emp_date_agg DISABLE QUERY REWRITE; When you want to get rid of an Mview that you’ve created, it’s as simple as using the DROP MATERIALIZED VIEW command. Appendix E has the syntax for this com- mand, and you’ve already seen it used here in this chapter. DROP MATERIALIZED VIEW mv_emp_date_agg; As you might expect, if you want to drop an Mview in a schema other than your own, you need the DROP ANY MATERIALIZED VIEW privilege. “But I Already Have Aggregate Tables!” So, you were ahead of the curve, and you already have a warehouse full of tables that act like materialized views. Oracle rewards you by allowing you to create an Mview on an existing table. To do this, you use the ON PREBUILT TABLE clause of the CREATE MATERIALIZED VIEW command. There are a few rules to follow for using existing aggregate tables: • The number of columns and column names in the table must match those in the query used in the CREATE MATERIALIZED VIEW command. • The table must be in the same schema as the materialized view being created. • The table must have the same name as the materialized view being created. Note: Keep in mind that the Mview you create with the ON PREBUILT TABLE clause will replace the table of the same name. Thus, that table will be converted into an Mview. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 879 Here’s an example of use of the ON PREBUILT TABLE clause: Create the table that we will convert to a MV CREATE TABLE emp_agg as SELECT TO_CHAR(hiredate,’yyyy’) Hireyear, COUNT(*) “Number Hired” FROM EMP GROUP BY TO_CHAR(hiredate,’yyyy’); Table created. Now, convert this into a MV using the ON PREBUILT TABLE clause. Note the name of the Mview is the same as the prebuilt table name. CREATE MATERIALIZED VIEW emp_agg ON PREBUILT TABLE REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE AS SELECT TO_CHAR(hiredate,’yyyy’) Hireyear, COUNT(*) “Number Hired” FROM EMP GROUP BY TO_CHAR(hiredate,’yyyy’); Data Dictionary Views for Mviews Several data dictionary views are provided for use with Mviews. They’re listed in Table 19.3. TABLE 19.3: MVIEW DATA DICTIONARY VIEWS View Name Description DBA_MVIEWS General information on materialized views in the database. MATERIALIZED VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 19 • ORACLE8i DATA WAREHOUSING FEATURES 880 TABLE 19.3: MVIEW DATA DICTIONARY VIEWS (CONTINUED) View Name Description ALL_REFRESH_DEPENDENCIES The last refresh information for objects on which Mviews are dependent. DBA_MVIEW_ANALYSIS Detailed information on Mviews, such as last refresh time and SCN. DBA_MVIEW_DETAIL_RELATIONS Mviews and their dependent base tables. DBA_MVIEW_JOINS Information on join conditions within Mviews. DBA_MVIEW_KEYS Various information on Mview relationships. For use with DBA_MVIEW_DETAIL_RELATIONS to get more details on Mview relationships. Refreshing Mviews When you create a materialized view, you want to make sure that Oracle keeps it updated to reflect the current data in the underlying tables. There are different ways to do this, depending on the type of materialized view you are using. The refresh mode available for a given Mview depends on whether it has joins and aggregates, joins and no aggregates, or is an aggregate Mview without any joins. There are two refresh options: • REFRESH ON COMMIT causes the Mview to be refreshed upon the COMMIT of any transaction that is changing the underlying base tables of the view. • REFRESH ON DEMAND delays the refresh of the materialized view until a ware- house refresh job is executed. We will discuss warehouse refresh later in this chapter. You also need to select the refresh method to be used by Oracle when actually refreshing the view. There are five refresh method choices, each with its own use restrictions: FAST, COMPLETE, FORCE, NEVER, and ALWAYS. Let’s take a closer look at the refresh options and refresh methods. Mview Refresh Options As mentioned, two refresh options are made available when you create a materialized view. You can also alter an Mview to change its refresh option. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 881 Refresh on Commit The REFRESH ON COMMIT option of the CREATE MATERIALIZED VIEW command is allowed in only two cases. The first is when the Mview is based on a single table (and is likely aggregating one or more columns of that table). The second case is when the Mview is created by joining two or more tables together, but the view contains no aggregates. Other restrictions also apply. Generally when you are doing a refresh on commit, you’ll want to be able to use the fast refresh method, and restrictions are associated with that as well. Refresh on Demand The REFRESH ON DEMAND option of the CREATE MATERIALIZED VIEW command is the default refresh option for any Mview created. Mview Refresh Methods The various refresh methods can be a bit confusing—in particular fast refresh and com- plete refresh. Here we’ll examine their functionality and the rules associated with them. Fast Refresh A fast refresh, also known as an incremental refresh, causes only the changed rows in the Mviews to be changed. Only rows that contain aggregates based on the changed rows of the base view will be changed in the Mview. Fast refresh is probably the best option, but there are a number of restrictions on it. If you wish to do a fast refresh of your Mview upon commitment of changes to the base table, an associated Mview log must be created on the base table. To do this, use the CREATE MATERIALIZED VIEW LOG command, and in the WITH clause define which columns you want to track in the log. In order to fast refresh the Mview, you must include the columns involved in the primary key of the base table. (More infor- mation on Mview logs can be found later in this chapter.) Here are the general rules for employing fast refresh: • The tables in the FROM clause cannot be views. • Mviews cannot contain nonrepeating expressions such as SYSDATE or ROWNUM, or nonrepeating PL/SQL functions. • LONG RAW and LONG data types are not supported for fast refresh. • You cannot use the HAVING and CONNECT BY clauses. • The WHERE clause can only contain inner and outer equijoins. All joins must be connected with ANDs. • Fast refresh does not support subqueries, inline views, or use of the UNION, UNION ALL, INTERSECT, or MINUS operations. MATERIALIZED VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 19 • ORACLE8i DATA WAREHOUSING FEATURES 882 The restrictions on use of fast refresh depend on the type of Mview. They are as follows: View with joins and aggregates The SELECT list must include all the columns of the GROUP BY clause. • An aggregate function is not required, but if one is used it can only include the following: SUM, COUNT(column), COUNT(DISTINCT column), COUNT(*), AVG, VARIANCE, STDDEV, MIN, and MAX. • There may be other restrictions. You may well be able to use the fast refresh method, but still have to refresh on demand. NOTE You cannot perform fast refreshes for updates to base tables of Mviews that con- tain joins and aggregates. Fast refreshes are only possible for operations that add data to the Mview using direct load operations (for example, direct load path SQL*Loader imports or INSERTS using the APPEND hint). Single-table aggregate Mview Fast refresh (and even refresh on com- mit) is allowed with this type of view. Restrictions include the following: • The SELECT list must contain all GROUP BY columns. • You can use expressions in the SELECT and GROUP BY columns, but the expressions must be the same in both columns. • In a single-table Mview to be fast refreshed, the WHERE clause is not sup- ported. • A COUNT(*) must be included in the Mview SELECT list. • The MIN and MAX functions are not supported. • An Mview log must exist and must contain all columns to be referenced in the Mview. You must include the INCLUDING NEW VALUES clause of the Mview log. • If the AVG or SUM function is used, you must also use the COUNT function and include the same expression in the COUNT function as the AVG or SUM function. For example if you include a SUM(pay), you’ll also need to include a COUNT(pay) in the query of the Mview. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 883 Mviews containing only joins Mviews with joins only cannot contain any GROUP BY clauses. • If the WHERE clause contains outer joins, unique constraints must exist on the join columns of the inner join table. • The ROWIDs of all the tables in the FROM list must appear in the SELECT list within the query defining the Mview. • You must have an Mview log on each base table of the Mview, and the logs must contain the ROWIDs of the base tables. Complete Refresh If you choose complete refresh, your Mview will be completely rebuilt rather than just updated with the incremental changes to the base tables. Often, this is the only refresh method available for use. Its benefits include the fact that you don’t need to create a snapshot (Mview) log from the base tables of the Mview. The drawback, how- ever, is that the underlying table of the Mview is truncated before the refresh, and so there are no rows in the view until the refresh completes. Force Refresh Using the Force method tells Oracle that a fast refresh is the preferred method of updating the view, but to do a complete refresh if a fast refresh is not possible. Always and Never Always causes an unconditional refresh of the materialized view, and Never sup- presses the refresh altogether. The Data Warehouse Refresh Facility (DBMS_MVIEW) If your Mviews cannot be set to REFRESH ON COMMIT (which means they are set to REFRESH ON DEMAND), then you need another method of updating the Mviews that you have in your system. This is the purpose of the Warehouse Refresh facility of Oracle8i, which is present in the form of the DBMS_MVIEW package. The DBMS_MVIEW package contains a number of different procedures, but for the purposes of refreshing Mviews we are interested in the following: • DBMS_MVIEW.REFRESH, which refreshes a specific Mview • DBMS_MVIEW.REFRESH_ALL_MVIEWS, which refreshes all Mviews • DBMS_MVIEW.REFRESH_DEPENDENT, which refreshes all Mviews that are dependent on one or more base tables MATERIALIZED VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 19 • ORACLE8i DATA WAREHOUSING FEATURES 884 NOTE The DBMS_MVIEW package is also used to manage remote Mview updates. See Chapter 25 for more information on simple replication with Mviews. Setting Up DBMS_MVIEW The primary consideration for setting up the Warehouse Refresh facility is properly setting up the Oracle Job Scheduler. Table 19.4 lists the parameters that you need to configure and their purpose. Once you have set these parameters, you are ready to refresh the Mviews. TABLE 19.4: JOB SCHEDULER PARAMETERS PERTINENT TO DBMS_MVIEW Parameter Name Default Value Description JOB_QUEUE_PROCESSES 0 Determines the number of job queue processes that Oracle will start when the database starts. Each queue is capable of running one job at a time. Thus, if multiple queues are started, you can run refreshes in parallel. JOB_QUEUE_INTERVAL 60 Determines the amount of time (in sec- onds) that will elapse before a job queue process looks for another job to execute. UTL_FILE_DIR None Defines external directories that can be written to by the UTL_FILE procedure. NOTE JOB_QUEUE_PROCESSES is dynamically modifiable using the ALTER SYSTEM command. Changing the other parameters requires bouncing the database. Using DBMS_MVIEW.REFRESH The REFRESH procedure of the DBMS_MVIEW command is an overloaded procedure. This is to allow the DBA to pass in either a single table or a comma-delimited list of tables for refresh. This procedure has the following definitions: Argument Name Type In/Out Default? C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 885 LIST VARCHAR2 IN METHOD VARCHAR2 IN DEFAULT ROLLBACK_SEG VARCHAR2 IN DEFAULT PUSH_DEFERRED_RPC BOOLEAN IN DEFAULT REFRESH_AFTER_ERRORS BOOLEAN IN DEFAULT PURGE_OPTION BINARY_INTEGER IN DEFAULT PARALLELISM BINARY_INTEGER IN DEFAULT HEAP_SIZE BINARY_INTEGER IN DEFAULT ATOMIC_REFRESH BOOLEAN IN DEFAULT Argument Name Type In/Out Default? TAB TABLE OF VARCHAR2(227) IN/OUT METHOD VARCHAR2 IN DEFAULT ROLLBACK_SEG VARCHAR2 IN DEFAULT PUSH_DEFERRED_RPC BOOLEAN IN DEFAULT REFRESH_AFTER_ERRORS BOOLEAN IN DEFAULT PURGE_OPTION BINARY_INTEGER IN DEFAULT PARALLELISM BINARY_INTEGER IN DEFAULT HEAP_SIZE BINARY_INTEGER IN DEFAULT ATOMIC_REFRESH BOOLEAN IN DEFAULT Note that most of these parameters have default values, so in many cases you’ll only need to provide the table (or list of tables) to update and then the update method you wish to use. Table 19.5 describes the parameters for the REFRESH procedure. TIP Often the DBA will create a job (using the DBMS_JOBS package) in the Job Sched- uler to automate the execution of DBMS_MVIEW.REFRESH. See Chapter 20 for more infor- mation on DBMS_JOBS. TABLE 19.5: DBMS_MVIEW.REFRESH PARAMETERS Refresh Parameter Purpose LIST A comma-delimited list of Mviews to refresh. TAB A single Mview to refresh. MATERIALIZED VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 19 • ORACLE8i DATA WAREHOUSING FEATURES 886 TABLE 19.5: DBMS_MVIEW.REFRESH PARAMETERS (CONTINUED) Refresh Parameter Purpose METHOD The refresh method to use: A=Always, F=Fast, ?=Force, and C=Complete. ROLLBACK_SEG The name of a specific rollback segment to use when performing the refresh. PUSH_DEFERRED_RPC Set to TRUE always; used for updateable snapshots and has no effect with warehouse-based Mviews. REFRESH_AFTER_ERRORS Indicates whether the job should continue refreshing other Mviews if an error is encountered with any previous Mview refresh. Set to TRUE to continue the job. PURGE_OPTION Set to FALSE always. PARALLELISM Set to 0 always. HEAP_SIZE Set to 0 always. ATOMIC_REFRESH If TRUE, all refreshes are in one transaction. If False, all refreshes are in their own transaction. Listing 19.4 is an example of running DBMS_MVIEW.REFRESH. Listing 19.4: Using DBMS_MVIEW.REFRESH Query the existing view. Note that we have 14 records. SQL> SELECT empno, ename FROM EMP; EMPNO ENAME 7369 SMITH 7499 ALLEN 7521 WARD 7566 JONES 7654 MARTIN 7698 BLAKE 7782 CLARK 7788 SCOTT 7839 KING 7844 TURNER 7876 ADAMS 7900 JAMES 7902 FORD C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 887 7934 MILLER 14 rows selected. Query the associated Mview SQL> SELECT * FROM emp_agg; HIRE Number Hired 1980 1 1981 10 1982 2 1983 1 Add a new record. SQL> INSERT INTO emp VALUES (8000,’FREEMAN’,’KING’,NULL, SYSDATE, 4000,2000,10); 1 row created. SQL> commit; Note, the Mview is not updated. SQL> SELECT * FROM emp_agg; HIRE Number Hired 1980 1 1981 10 1982 2 1983 1 Use the warehouse refresh facility to update the Mview. SQL> BEGIN 2 DBMS_MVIEW.REFRESH(‘EMP_AGG’,’A’); 3 END; 4 / PL/SQL procedure successfully completed. Now, look at the Mview, it’s updated! SQL> SELECT * FROM emp_agg; MATERIALIZED VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.