I would drop the mview maintaining the table, then establish the mview post
upgrade on prebuilt table, then it is only a metadata change.
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf
Of Mark W. Farnham
Sent: Tuesday, September 22, 2020 11:14 AM
To: 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>
[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 <gokulkumar.gopal@xxxxxxxxx
<mailto:gokulkumar.gopal@xxxxxxxxx> > wrote:
We are currently migrating from 188.8.131.52 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.