Materialized views open up all sorts of possibilities for making reporting more efficient – but at the same time they can introduce some “interesting” side effects when you start seeing refreshes taking place. (Possibly one of the most dramatic surprises appeared in the upgrade that switched many refreshes into “atomic” mode, changing a “truncate / append” cycle into a massively expensive “delete / insert” cycle).
If you want to have some ideas of the type of work that is involved in the materialized view “fast refresh”, you could look at a recent pair of articles by Alberto Dell’Era on (very specifically) outer join materialized views (which a link back to a much older article on inner join materialized view refresh):
Related posts:
- refresh “fast” of materialized views optimized by Oracle as “complete”
- fast refresh of outer-join-only materialized views – algorithm, part 1
- fast refresh of join-only MVs: _mv_refresh_use_stats and locking log stats
- fast refresh of outer-join-only materialized views – algorithm, part 2
- Materialized view refresh change in 10G and sql tracing
- Materialized View Refresh ON COMMIT
- Materialized view refresh change in 10G and sql tracing
- ON COMMIT Refresh without a Primary Key
- BUILD DEFERRED takes ages
- Incremental refresh of Exalytics aggregates using native BI Server capabilities