Re: Materalized View Refresh after upgrade - Oracle 11g to 12c

  • From: Upendra nerilla <nupendra@xxxxxxxxxxx>
  • To: "jlewisoracle@xxxxxxxxx" <jlewisoracle@xxxxxxxxx>, 'Oracle-L Group' <Oracle-L@xxxxxxxxxxxxx>, "mwf@xxxxxxxx" <mwf@xxxxxxxx>
  • Date: Tue, 22 Sep 2020 19:01:32 +0000

In the past, when we had dependencies with large MVs during upgrade, here is 
the approach that worked for us..

  1.  We'd create the MVs using prebuilt table option
  2.  Stop all application connections and transactions to the base table
  3.  Drop the MV and MV log
  4.  Complete the upgrade
  5.  Recreate the MV log and MV using the pre-existing table

The advantage of this approach is that the pre-built (MV) table will retain the 
underlying MV structure and data even after the MV is dropped. At the end of 
the upgrade, we'd recreate the MV. We'd skip the full refresh and start 
incremental refresh. Since there were no changes made to the underlying table 
when the MV was recreated it shrunk the maintenance window significantly.

-Upendra

________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf 
of Mark W. Farnham <mwf@xxxxxxxx>
Sent: Tuesday, September 22, 2020 2:14 PM
To: jlewisoracle@xxxxxxxxx <jlewisoracle@xxxxxxxxx>; 'Oracle-L Group' 
<Oracle-L@xxxxxxxxxxxxx>
Subject: RE: Materalized View Refresh after upgrade - Oracle 11g to 12c


I do wonder, without having done any testing, whether it is fastest to actually 
drop the MVs, do the upgrade, and recreate the MVs, making that the last step 
of your version of the upgrade. I suppose it depends. That would certainly not 
leave any trash around.



This of course presumes that up to date DDL is available trivially with 
certainty. Which is of course true for every production database, right?



From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Jonathan Lewis
Sent: Tuesday, September 22, 2020 12:58 PM
To: Oracle-L Group
Subject: Re: Materalized View Refresh after upgrade - Oracle 11g to 12c





I'm wondering if someone has mis-interpreted the requirement to refresh all the 
existing MVs so that all the mv logs are empty before the upgrade.

A recent posting on the Developer Forum reported the following from the 
pre-upgrade (12.1 SE to 18c) assessment:

      Oracle recommends that all materialized views (MV's) are refreshed before

      upgrading the database because this will clear the MV logs and the

      sumdelta$ table, and make the UPGRADE process faster. If you choose to

      not refresh some MVs, the change data for those MV's will be carried

      through the UPGRADE process. After UPGRADE, you can refresh the MV's and

      MV incremental refresh should work in normal cases.

It's possible that your system will have different requirements because it's 
lower versions involved, but it doesn't sound as if there's anything in there 
to do with "old references not being valid".

The report does, however,, contain the following:



     If there are any stale

      MVs depending on changes in sys.sumdelta$, do not truncate it, because

      doing so will cause wrong results after refresh.

This, perhaps, is where the "old references not being valid" is supposed to be 
relevant.



Regards

Jonathan Lewis







On Tue, 22 Sep 2020 at 17:43, Gokul Kumar Gopal 
<gokulkumar.gopal@xxxxxxxxx<mailto:gokulkumar.gopal@xxxxxxxxx>> wrote:

Hello,



We are currently migrating from 11.2.0.4 to 12.2.



There are about 150 materialized view logs on the basetables.



Several consumers refresh the MVs using these MV logs (on demand fast refresh).



We are now told that due to migration, the MVs will have to be refreshed in 
FULL, because all the old references are no longer valid.



I have not found anything in the documentation to this effect.



I would like to confirm with the experts in the forum if this is the case.



Rgds,

Gokul

Other related posts: