Dependencies related to materialized views are automatically maintained to ensure
correct operation. When a materialized view is created, the materialized view depends on the detail tables referenced in its definition.
Any DML operation, such as an INSERT, or DELETE, UPDATE, or DDL operation on any dependency in the
materialized view will cause it to become invalid. To revalidate a materialized view, use the ALTER MATERIALIZED VIEW COMPILE statement.
A materialized view is automatically revalidated when it is referenced. In many cases, the materialized view will be successfully and transparently revalidated. However, if a column has been dropped in a table referenced by a materialized view or the owner of the materialized view did not have one of the query rewrite privileges and that privilege has now been granted to the owner, you should use the following statement
to revalidate the materialized view:
ALTER MATERIALIZED VIEW mview_name COMPILE;
The state of a materialized view can be checked by querying the data dictionary views
USER_MVIEWS or ALL_MVIEWS.
The column STALENESS will show one of the values FRESH, STALE, UNUSABLE, UNKNOWN, UNDEFINED, or NEEDS_COMPILE to indicate
whether the materialized view can be used. The state is maintained automatically.
However, if the staleness of a materialized view is marked as NEEDS_COMPILE, you could issue an
ALTER MATERIALIZED VIEW ... COMPILE
statement to validate the materialized view and get the correct staleness state. If the state of a materialized view
is UNUSABLE, you must perform a complete refresh to bring the materialized view back to the FRESH state. If the materialized view is based on a prebuilt table that you never refresh, you must drop and re-create the materialized view. The staleness of
remote materialized views is not tracked. Thus, if you use remote materialized views for rewrite, they are considered to be trusted.