|
An attempt to alter the schema defined for a table or view requires that the database server consider if there are dependent views impacted by the change. Examples of schema-altering operations include:
Dropping a table, view, materialized view, or column
Renaming a table, view, materialized view, or column
Adding, dropping, or altering columns
Altering a column's data type, size, or nullability
Disabling views or table view dependencies
When you attempt a schema-altering operation, the following events occur:
The database server generates a list of views that depend directly or indirectly upon the table or view being altered. Views with a DISABLED status are ignored.
If any of the dependent views are materialized views, the request fails, an error is returned, and the remaining events do not occur. You must first disable dependent materialized views before proceeding with the operation. See Enabling and disabling materialized views.
The database server obtains exclusive schema locks on the table or view being modified, as well as on all dependent views.
The database server sets the status of all dependent views to INVALID.
The database server performs the schema-altering operation. If the operation fails, the locks are released, the status of dependent views is reset to VALID, an error is returned, and the following step does not occur.
The database server recompiles the dependent views, setting each view's status to VALID when successful. If compilation fails for any view, the status of that view remains INVALID. Subsequent requests for an INVALID view causes the database server to attempt to recompile the view. If subsequent attempts fail, it is likely that an alteration is required on the INVALID view, or on an object upon which it depends, for it to compile successfully.