RE: redo curiosity
- From: "Stephens, Chris" <Chris.Stephens@xxxxxxx>
- To: "maureen.english@xxxxxxxxxx" <maureen.english@xxxxxxxxxx>, "Oracle-l@xxxxxxxxxxxxx" <Oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 19 Feb 2010 14:41:28 -0600
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Maureen English
Sent: Friday, February 19, 2010 2:39 PM
To: Oracle-l@xxxxxxxxxxxxx
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
>
--
//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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
