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.
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'
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
On Tue, 22 Sep 2020 at 17:43, Gokul Kumar Gopal
We are currently migrating from 126.96.36.199 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.