if atomic refresh is set to TRUE, materialized view truncate andWith atomic refreshes the materialized view is not truncated, it is deleted. That delete is performed in the same transaction as the updating.
refresh happens in one transaction
I am not sure if this uses dbms_mview to refresh.If you execute the following query you should be able to find out the call used for the refresh.
Probably it would take longer to refresh because of deleteThis is not only probable, it is sure.
command instead of truncate command.
Below is the output from dba_jobs.Mhmm... the call to the procedure refresh should have some parameters...
am assuming it is using dbms_refresh command. Is it different from dbms_mview ?Yes. The package dbms_refresh is designed to refresh a so-called "refresh group", not only a materialized view.
What should I do to force oracle to use dbms_mview.If the refresh options in the CREATE MATERIALIZED VIEW statement creates this job, IMHO, the only way to do it is to:
Our materialized view will have about 1 million records.The decision should not be based on the number of rows. But on the amount of time and resources you have to refresh the MV.
I guess atomic refresh may not even worth considering.
let me know if this is a good idea or is this soundsI know a couple of environments where there are multiple copies of the "same" table for similar purposes. All of them simply use synonyms. Simply put, the application references only a synonym. The job in charge for the refresh, before starting it, alters the synonym to reference another table. In this way no special coding is necessary in the application.
stupid or if we are re-engineering too much.