Re: redo curiosity

Decisions, decisions....  Do we want speed and fewer redo logs, or do we want 
to guarantee
consistent queries?

If the behavior in 8i is to truncate, then our users shouldn't even notice the 
difference in
behavior, but they may notice the difference in refresh times.  On the other 
hand, the
refreshes in the 10g database currently take about the same amount of time as 
the refreshes
in the 8i database...and disk space isn't really an issue....

*I* want the refreshes to go faster and generate less redo, but I'm pretty sure 
that from
a user point of view, the read-consistency is far more important.

For now, I'm leaving our nightly refreshes as they are.

Thanks to all who added their $.02 here!

- Maureen


Allen, Brandon wrote:
No problem, I'm sure atomic_refresh=>false will make a big difference in performance and redo size, but just beware of the affect on read-consistency if you're refreshing multiple views and also the fact that anything that queries the MV during the refresh could get zero rows if it queries after the truncate, but before the new rows are inserted. MOS 553464.1 has more detail. 

Regards,
Brandon


--
http://www.freelists.org/webpage/oracle-l

Other related posts: