RE: redo curiosity

From: Stephens, Chris <Chris.Stephens_at_adm.com>
Date: Fri, 19 Feb 2010 14:41:28 -0600
Message-ID: <D95BD5AFADBB0F4E9BB6C53F14D3A050049CF1A799_at_JRCEXC1V1.research.na.admworld.com>

There is the 3rd alternative the Mark proposed which I'm going to be doing at my current place of employment. I have no idea why I didn't think of this before.

That would be messing with synonyms and keeping multiple copies of materialized views.

Thanks Mark!!

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Maureen English Sent: Friday, February 19, 2010 2:39 PM
To: Oracle-l_at_freelists.org
Subject: 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



CONFIDENTIALITY NOTICE:
        This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law.  If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.  If you have received this communication in error, please notify us immediately by email reply.


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

Received on Fri Feb 19 2010 - 14:41:28 CST