DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=syz9gPxoUw2qFdPFasYG05wI8GSLBMU9tTI2UdSkodpIWP6MsrTJineY9xcZxnei0EGB/GrAOl9GdamZCGo+uPMn38PP6A4oAP4V+UueKzpHPXVTV5dyrCTMAggUEXQHZdMPcuvUYSUVcszxRfLunl1bioYxZnSzMwRH9YMZTVc=
Message-ID: <7b8774110712160501k7cf8d570ic6dd587c98e00774@mail.gmail.com>
Date: Sun, 16 Dec 2007 07:01:53 -0600
From: "Charles Schultz" <sacrophyte@gmail.com>
To: grzegorzof@interia.pl
Subject: Re: does FRA is really needed ?
Cc: oracle-l@freelists.org
In-Reply-To: <476511C6.3070709@interia.pl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_5245_31816150.1197810113073"
References: <916349.5896.qm@web58006.mail.re3.yahoo.com>
	 <4025610e0712150927l31a88113o36cc4aac77056c69@mail.gmail.com>
	 <476511C6.3070709@interia.pl>
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: sacrophyte@gmail.com
------=_Part_5245_31816150.1197810113073
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Grzegorz,

Good question, that is something we have been wondering about as well. There
are some other questions that go along with this, I believe.

For instance, are you using a RAC? Seems like an obvious one, but I did not
want to assume (that BAAG party as got to be for something, right?). Second
question, do you currently or plan to use Flashback database? From my
limited experience, these seem to be the key things that "require" an FRA.

To answer you question, dataguard, in and of itself, does not need FRA
whatsoever. In fact, DG and RAC are two completely separate technologies,
used to achieve a single goal (Maximum Availability).

In our RAC environment, we do not currently have need of an FRA; we
implemented the Flashback Recovery Area as part of the "Best Practices", but
for us, it is a real pain dealing with archive log gaps (both for physical
standbys and streams). And we have chosen, at this point, to avoid the
dataguard broker as well. These are choices we have made for our particular
environment and may not be well suited for everyone. We are still learning
things about RAC, FRA and the broker, so there is still a chance our
environment may change a little.

If anyone finds holes this, please let me know. =)

On Dec 16, 2007 5:53 AM, Grzegorz Goryszewski <grzegorzof@interia.pl> wrote:

> Hi,
>
>    can You please clarify one thing for me.
> I'm wonder if FRA is really neccessary for Data Guard solution ?
> I'm preparing for DG configuration with physical standby, do I need FRA
> for
> failover switch from primary to standby and back ?
> Oracle 10.2.0.2 .
> Regards.
> Grzegorz
>
>
> ----------------------------------------------------------------------
> Las Vegas wsrod portali! Sprawdz >> http://www.interia.pl/
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>


-- 
Charles Schultz

------=_Part_5245_31816150.1197810113073
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Grzegorz,<br><br>Good question, that is something we have been wondering about as well. There are some other questions that go along with this, I believe.<br><br>For instance, are you using a RAC? Seems like an obvious one, but I did not want to assume (that BAAG party as got to be for something, right?). Second question, do you currently or plan to use Flashback database? From my limited experience, these seem to be the key things that &quot;require&quot; an FRA.
<br><br>To answer you question, dataguard, in and of itself, does not need FRA whatsoever. In fact, DG and RAC are two completely separate technologies, used to achieve a single goal (Maximum Availability).<br><br>In our RAC environment, we do not currently have need of an FRA; we implemented the Flashback Recovery Area as part of the &quot;Best Practices&quot;, but for us, it is a real pain dealing with archive log gaps (both for physical standbys and streams). And we have chosen, at this point, to avoid the dataguard broker as well. These are choices we have made for our particular environment and may not be well suited for everyone. We are still learning things about RAC, FRA and the broker, so there is still a chance our environment may change a little.
<br><br>If anyone finds holes this, please let me know. =)<br><br><div class="gmail_quote">On Dec 16, 2007 5:53 AM, Grzegorz Goryszewski &lt;<a href="mailto:grzegorzof@interia.pl">grzegorzof@interia.pl</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br> &nbsp; &nbsp;can You please clarify one thing for me.<br>I&#39;m wonder if FRA is really neccessary for Data Guard solution ?<br>I&#39;m preparing for DG configuration with physical standby, do I need FRA for<br>failover switch from primary to standby and back ?
<br>Oracle <a href="http://10.2.0.2" target="_blank">10.2.0.2</a> .<br>Regards.<br>Grzegorz<br><br><br>----------------------------------------------------------------------<br>Las Vegas wsrod portali! Sprawdz &gt;&gt; <a href="http://www.interia.pl/" target="_blank">
http://www.interia.pl/</a><br><font color="#888888"><br><br>--<br><a href="http://www.freelists.org/webpage/oracle-l" target="_blank">http://www.freelists.org/webpage/oracle-l</a><br><br><br></font></blockquote></div><br>
<br clear="all"><br>-- <br>Charles Schultz

------=_Part_5245_31816150.1197810113073--
--
http://www.freelists.org/webpage/oracle-l