Slow Materialized View Complete Refresh Issues Resolved….

I was recently working on tuning – production environment, which had number of materilazed 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 complaning about sudden change in materialed view behaviour, after they upgraded database from 9i to 11g.

After reading Oracle documentation about materialized views I found, the reason for this sudden behavoiur 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

Advertisements