ATOMIC_REFRESH
?

Учтите, что в этом случае, после truncate и неудавшемся обновления вьюшки, она окажется полностью пустой. Да и на время обновления, запросившему из неё данные ничего не вернётся.
Уточните, насколько это критично, по времени и действию, для бизнес-процессов.

Denis@nkгде об этом написано в документации?
http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_mview.htm#ARPLS67205
atomic_refreshIf this parameter is set to true, then the list of materialized views is refreshed in a single transaction. All of the refreshed materialized views are updated to a single point in time. If the refresh fails for any of the materialized views, none of the materialized views are updated.

If this parameter is set to false, then each of the materialized views is refreshed in a separate transaction.

As part of complete refresh, if truncate is used (non-atomic refresh) , unique index rebuild is executed. INDEX REBUILD automatically computes statistics. Thus, statistics are updated for truncated tables.
Tune Complete Refresh of Materialized View by atomic_refresh=>false

https://docs.oracle.com/database/121/DWHSG/refresh.htm#DWHSG-GUID-64068234-BDB0-4C12-AE70-75571046A586 For refresh using DBMS_MVIEW.REFRESH, set the parameter atomic_refresh to FALSE.

* For COMPLETE refresh, this causes a 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 uses 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 is able to use the TRUNCATE optimizations described earlier.