Cutover doesn't regenerate MVs unless they are out-of-date.
A materialized view becomes out-of-date in the following conditions;
1)when the Logical View is patched
2)anything which the Logical View depends on is patched or recompiled
3)any seed data table the materialized view depends on is prepared for loading new content in the patch edition.
This applies all the MVs, including the big ones.
Also note the following->
When a MV regeneration is required, cutover tries to preserve the existing MV container table (with its data), but if the shape of the container table must change, then the container table is dropped and recreated automatically.
This kind of a renegeration usually takes time, and you can't tune it by doing something in the adop's layer.
*Concantrate on reducing the downtime required for your MV regeneration.. MV regeneration itself...(with or without adop/cutover phase in mind)
*There is also a manual way for bypassing the MV generation.
This way you may alter the materialized view structure without a full rebuild of the data.
Ofcourse you should test it..
Connor Mcdonald explains it in the following blog post;
https://connor-mcdonald.com/2018/09/10/modifying-tables-without-losing-materialized-views/It is simply based on
-doin a last fast refresh
-dropping the MV definition , but preserving the MV table (as a standalone table)
-doing the necessary alter on the standalone table
-executing the your cutover
-recreating your MV log
-recreating your MV on top of the standalone table using the PREBUILT table clause.
Also note that,
In the finalize phase, adop prepares the list of actions that it will take in the cutover phase.
It stores this actions in the table called ad_zd_ddl_handler
So, after the finalize phase, you can check this table to see if your big MV will be generated in the cutover phase or not..
you can use a simple query like the following to check;
select ddl_id, sql_lob from ad_zd_ddl_handler
where phase='CUTOVER'
and sql_lob like '%mview%';
Locked
