Unbreakable Materialized Views

Oracle8i: Invalidating a Materialized View

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 DDL operation, such as a DROP or ALTER, on any dependency in the materialized view will cause it to become invalid.

Oracle9i: Invalidating Materialized Views

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 a INSERT, or DELETE, UPDATE, or DDL operation on any dependency in the materialized view will cause it to become invalid.

Oracle10g: Invalidating Materialized Views

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.

RTFM

In 9i and 10g, a materialized view becomes automatically invalid when performing DML or DDL. Don't worry:

A materialized view is automatically revalidated when it is referenced. In many cases, the materialized view will be successfully and transparently revalidated.

Suppose you have a materialized view on EMP and your application aborts immediate after logon when invalid objects are found. The "early bird" user modifies the EMP table and all others users cannot start the application anymore. I hear the sound of a ringing phone...