RE: redo curiosity

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Thu, 18 Feb 2010 17:17:33 -0500
Message-ID: <4D8F2039498B4252AD9F3527D520D2D6_at_rsiz.com>



Of course if you want to support a clean break while allowing running previous queries to complete, then you can use the rotating synonyms game to as many versions of the mv as you have room for (usually two is plenty) with the added advantage that if you only let "the folks" access the mv via the synonym, then no one else is accessing the mv you are refreshing at all, which avoids all sorts of concurrency overhead. And while Oracle handles concurrency overhead very well, avoiding it is superior.

mwf

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Allen, Brandon
Sent: Thursday, February 18, 2010 4:35 PM To: Maureen English; Oracle-l_at_freelists.org Subject: RE: redo curiosity

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

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.
--

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

--

http://www.freelists.org/webpage/oracle-l Received on Thu Feb 18 2010 - 16:17:33 CST

Original text of this message