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
Adityanath's Database & Cloud Blog 
Leave a reply to Anonymous Cancel reply