(Sources www.oracle.com and www.databasejournal.com)

A materialized view is a database object that contains the results of a query. They are local copies of data located remotely, or are used to create summary tables based on aggregations of a table’s data. A materialized view can query tables, views, and other materialized views. Collectively these are called master tables (a replication term) or detail tables (a data warehouse term).

For replication purposes, materialized views allow you to maintain copies of remote data on your local node. These copies are read-only. If you want to update the local copies, you have to use the Advanced Replication feature. You can select data from a materialized view as you would from a table or view.

Materialized views, which store data based on remote tables are also, know as snapshots.

Why Use Materialized Views?

You can use materialized views to achieve one or more of the following goals:

• Ease Network Loads
• Create a Mass Deployment Environment
• Enable Data Sub-setting
• Enable Disconnected Computing

Ease Network Loads à If one of your goals is to reduce network loads, then you can use materialized views to distribute your corporate database to regional sites. Instead of the entire company accessing a single database server, user load is distributed across multiple database servers. Through the use of multi-tier materialized views, you can create materialized views based on other materialized views, which enables you to distribute user load to an even greater extent because clients can access materialized view sites instead of master sites. To decrease the amount of data that is replicated, a materialized view can be a subset of a master table or master materialized view.

In addition to not requiring a dedicated network connection, replicating data with materialized views increases data availability by providing local access to the target data. These benefits, combined with mass deployment and data sub-setting (both of which also reduce network loads), greatly enhance the performance and reliability of your replicated database.

Create a Mass Deployment Environmentà Deployment templates allow you to pre-create a materialized view environment locally. You can then use deployment templates to quickly and easily deploy materialized view environments to support sales force automation and other mass deployment environments. Parameters allow you to create custom data sets for individual users without changing the deployment template. This technology enables you to roll out a database infrastructure to hundreds or thousands of users.

Enable Data Sub-settingà Materialized views allow you to replicate data based on column- and row-level sub-setting, while multimaster replication requires replication of the entire table. Data sub-setting enables you to replicate information that pertains only to a particular site. For example, if you have a regional sales office, then you might replicate only the data that is needed in that region, thereby cutting down on unnecessary network traffic.

Enable Disconnected Computingà Materialized views do not require a dedicated network connection. Though you have the option of automating the refresh process by scheduling a job, you can manually refresh your materialized view on-demand, which is an ideal solution for sales applications running on a laptop. For example, a developer can integrate the replication management API for refresh on-demand into the sales application. When the salesperson has completed the day’s orders, the salesperson simply dials up the network and uses the integrated mechanism to refresh the database, thus transferring the orders to the main office.

Read-Only Materialized Views

You can make a materialized view read-only during creation by omitting the FOR UPDATE clause or disabling the equivalent option in the Replication Management tool. Read-only materialized views use many of the same mechanisms as updatable materialized views, except that they do not need to belong to a materialized view group. In addition, using read-only materialized views eliminates the possibility of a materialized view introducing data conflicts at the master site or master materialized view site, although this convenience means that updates cannot be made at the remote materialized view site. The following is an example of a read-only materialized view:

CREATE MATERIALIZED VIEW hr.employees

AS

SELECT * FROM hr.employees@orc1.world

Updatable Materialized Views

You can make a materialized view updatable during creation by including the FOR UPDATE clause or enabling the equivalent option in the Replication Management tool. For changes made to an updatable materialized view to be pushed back to the master during refresh, the updatable materialized view must belong to a materialized view group. Updatable materialized views enable you to decrease the load on master sites because users can make changes to the data at the materialized view site. The following is an example of an updatable materialized view:

CREATE MATERIALIZED VIEW hr.departments

FOR UPDATE AS

SELECT * FROM hr.departments@orc1.world;

Primary Key Materialized Views

The following statement creates the primary-key materialized view on the table emp located on a remote database.

CREATE MATERIALIZED VIEW mv_emp_pk

REFRESH FAST START WITH SYSDATE

NEXT SYSDATE + 1/48

WITH PRIMARY KEY

AS

SELECT * FROM emp@remote_db;

Note: When you create a materialized view using the FAST option you will need to create a view log on the master tables(s) as shown below:

CREATE MATERIALIZED VIEW LOG ON emp;

Rowid Materialized Views

The following statement creates the rowid materialized view on table emp located on a remote database:

CREATE MATERIALIZED VIEW mv_emp_rowid

REFRESH WITH ROWID

AS

SELECT * FROM emp@remote_db;

Subquery Materialized Views

The following statement creates a subquery materialized view based on the emp and dept tables located on the remote database:

CREATE MATERIALIZED VIEW mv_empdept

AS

SELECT *

FROM emp@remote_db e

WHERE EXISTS ( SELECT * FROM dept@remote_db d

WHERE e.dept_no = d.dept_no)

REFRESH CLAUSE

[refresh [fast|complete|force]

[on demand | commit]

[start with date] [next date]

[with {primary key|rowid}]]

The refresh option specifies:

• The refresh method used by Oracle to refresh data in materialized view
• Whether the view is primary key based or row-id based
• The time and interval at which the view is to be refreshed

Refresh Method - FAST Clause

The FAST refreshes use the materialized view logs (as seen above) to send the rows that have changed from master tables to the materialized view. You should create a materialized view log for the master tables if you specify the REFRESH FAST clause.

CREATE MATERIALIZED VIEW LOG ON emp;

Materialized views are not eligible for fast refresh if the defined subquery contains an analytic function.

Refresh Method – COMPLETE Clause

The complete refresh re-creates the entire materialized view. If you request a complete refresh, Oracle performs a complete refresh even if a fast refresh is possible.

Refresh Method – FORCE Clause

When you specify a FORCE clause, Oracle will perform a fast refresh if one is possible or a complete refresh otherwise. If you do not specify a refresh method (FAST, COMPLETE, or FORCE), FORCE is the default.

PRIMARY KEY and ROWID Clause

WITH PRIMARY KEY is used to create a primary key materialized view i.e. the materialized view is based on the primary key of the master table instead of ROWID (for ROWID clause). PRIMARY KEY is the default option. To use the PRIMARY KEY clause you should have defined PRIMARY KEY on the master table or else you should use ROWID based materialized views.

Primary key materialized views allow materialized view master tables to be reorganized without affecting the eligibility of the materialized view for fast refresh.

Rowid materialized views should have a single master table and cannot contain any of the following:

• Distinct or aggregate functions
• GROUP BY Subqueries , Joins & Set operations

Timing the refresh

The START WITH clause tells the database when to perform the first replication from the master table to the local base table. It should evaluate to a future point in time. The NEXT clause specifies the interval between refreshes

CREATE MATERIALIZED VIEW mv_emp_pk

REFRESH FAST

START WITH SYSDATE

NEXT SYSDATE + 2

WITH PRIMARY KEY

AS

SELECT * FROM emp@remote_db;

In the above example, the first copy of the materialized view is made at SYSDATE and the interval at which the refresh has to be performed is every two days.

Truncates are DDL (Data Definition Language) and, in a sense, cheat. A truncate moves the High Water Mark of the table back to zero. No row-level locks are taken; no redo or rollback is generated. All extents bar the initial are de-allocated from the table (if you have MINEXTENTS set to anything other than 1, then that number of extents is retained rather than just the initial). By re-positioning the high water mark, they prevent reading of any table data, so they have the same effect as a delete, but without all the overhead. Just one slight problem: a truncate is a DDL command, so you can’t roll it back if you decide you made a mistake. (It’s also true that you can’t selectively truncate – no “WHERE” clause is permitted, unlike with deletes, of course).

By resetting the High Water Mark, the truncate prevents reading of any table’s data, so they it has the same effect as a delete, but without the overhead. There is, however, one aspect of a Truncate that must be kept in mind. Because a Truncate is DDL it issues a COMMIT before it acts and another COMMIT afterward so no rollback of the transaction is possible.

Example:-

SQL> create table testron
2  (testcol varchar2(20));

Table created.

SQL> select sum(blocks)
2  from user_extents
3  where segment_name = ‘TESTRON’
4  /

SUM(BLOCKS)

———–
8

SQL> begin
2  for i in  1..10000
3  Loop
4   insert into testron
5   values(‘truncate karunga’);
6  end loop;
7  commit;
8  end;
9  /

PL/SQL procedure successfully completed.
SQL> select sum(blocks)
2  from user_extents
3  where segment_name = ‘TESTRON’
4  /

SUM(BLOCKS)

———–
32

SQL> truncate table testron
2  /

Table truncated.

SQL> select sum(blocks)
2  from user_extents
3  where segment_name = ‘TESTRON’
4  /

SUM(BLOCKS)

———–
8

Welcome to Oracle Apps Stuff Blog. I have created this blog in order to keep certain technical documents, notes and articles from different sources on the web, and some of my own experiences under one roof. This blog is for all those who are new to Oracle Applications. I shall be putting in some stuff which I have faced in my proffessional career. Well, this blog would mostly cover Oracle Applications modules, customizations, PL/SQL, Unix Shell Scripting and stuffs like these along with a few selected articles may be.

For now, thank you for reading the blog and I shall come up with the first tech post pretty soon.

Thank you!!!