Question

I am looking for the life cycle of an Oracle materialized view. For example the statement:

Create materialized view foo
Refresh On Commit
...

Will this view be updated every time there is a commit to my database, or just one of the tables referenced in the view statement? Also beyond this at what point does Oracle destroy the old cache and replace it with the new one? Specifically what is the window of “staleness” for a materialized view? Meaning is it dependent on how long it takes to create the materialized view.

Answer 1

The ON COMMIT clause will modify the commit process of all transactions that issue DML on a base table:

Specify ON COMMIT to indicate that a fast refresh is to occur whenever the database commits a transaction that operates on a master table of the materialized view. This clause may increase the time taken to complete the commit, because the database performs the refresh operation as part of the commit process.

The commit will be dependent upon the success of the refresh of the materialized view (which means that a commit can fail because a dependent MV can’t be refreshed).

The refresh takes place in the same transaction as the one that issues the commit. This means that as soon as the commit is complete, the changes are visible to all sessions (data is thus never stale).

Some of the things you have to be aware of:

• The use of on-commit MVs has a performance cost: materialized view logs (adds DML “triggers” to the base table) increase the work on DML and obviously the commit will perform more work than usual. Benchmark your workload to make sure the extra work won’t be a burden.
• In aggregate on-commit MV, concurrent transactions can update the same MV row, which can lead to some contention during the commit on top of the extra work.
• Some tools don’t expect a commit to fail, this can lead to some UI problems (usually old client-server apps).