I was recently working on tuning – production environment, which had number of materialized views which were scheduled to complete refresh during off hours.

This complete refresh process was very time consuming, also producing a large amount archivelogs & undo.

Customer was complaining about sudden change in materialized view behavior, after they upgraded database from 9i to 11g.

After reading Oracle documentation about materialized views I found, the reason for this sudden behavior change.

From 10g, Oracle has changed the default parameter value of ATOMIC_REFRESH in the DBMS_MVIEW.REFRESH package.

In earlier releases (before 10g) the parameter was set to FALSE by default but now it is set to TRUE, which forces a DELETE of the materialized view instead of TRUNCATE, making the materialized view more “available” at refresh time.

Advantages of ATOMIC_REFRESH => FLASE

• No or very less archive generation
• Complete refresh process is very fast as compared to process with ATOMIC_REFRESH => TRUE

Disadvantages of ATOMIC_REFRESH => FLASE

• Unavailability of data during the refresh process, which could be unacceptable to application and business user.

After discussing with customer, I made changes in refresh methodology so as to use ATOMIC_REFRESH => FLASE.

          Time Taken          Archive generation
Before    Approx. 43 minutes  Approx. 68 
After     Approx. 6 minutes   Approx. 7

Usage:

EXEC DBMS_MVIEW.REFRESH(‘MVIEW1’, METHOD => ‘C’, ATOMIC_REFRESH => FALSE);

Hope so this post is useful for you 🙂

Cheers

Regards,

Adityanath