The default action follows Oracle's read-consistent model, meaning users querying the materialized view will simply see the changes appear at some point. The refresh is done with a delete (transactional + insert). If you want to speed it up (and risk a user receiving invalid results for a split second) then use atomic_refresh option, setting to FALSE. It is good to schedule your refreshes during night / low transaction hours, and atomic_refresh is ok to use for speed if you can afford it. However, if your business requirements do NOT allow the view to be invalid for just a few seconds during the refresh, don't use that option.
See the docs:
http://download.oracl
<quote>
For
For COMPLETE refresh, this will TRUNCATE to delete existing rows in the materialized view, which is faster than a delete.
For PCT refresh, if the materialized view is partitioned appropriately, this will use TRUNCATE PARTITION to delete rows in the affected partitions of the materialized view, which is faster than a delete.
For FAST or FORCE refresh, if COMPLETE or PCT refresh is chosen, this will be able to use the TRUNCATE optimizations described earlier.
</quote>
Main Topics
Browse All Topics
by: angelIIIPosted on 2009-11-04 at 02:30:39ID: 25737941
the underlying tables will only be queried by the MV refresh, so will not affect other users's ability to read those tables.
the users will get issues reading from the MV itself.