In-Reply-To: <47666775.9060106@interia.pl>
To: grzegorzof@interia.pl
Cc: Alex Gorbachev <ag@oracloid.com>,
 oracle-l@freelists.org,
 oracle-l-bounce@freelists.org
Subject: Re: does FRA is really needed ?
MIME-Version: 1.0
Message-ID: <OFE306D386.A3581194-ON802573B4.004737F1-802573B4.0048E0D8@nominet.org.uk>
From: "Jason Arneil" <Jason@nominet.org.uk>
Date: Mon, 17 Dec 2007 13:16:01 +0000
Content-Type: text/plain; charset="US-ASCII"
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: Jason@nominet.org.uk

oracle-l-bounce@freelists.org wrote on 17/12/2007 12:11:33:

> Alex Gorbachev pisze:
> > Just two things to mention:
> >
> > - can have FRA but you don't have to backup your datafiles there or
> > even put your archivelogs there. you can manage all of it separately.
> > FRA is the only destination for flashback logs but that's it. Is
> > flashback logs what you need to restore quickly (i.e. without
> > rebuilding of the new standby) after switchover. You need to flashback
> > the database and flashback logs can only be stored in FRA. Thus, FRA
> > requirements but in fact it's enabled flashback logging that's
> > required. Am I right?
> > 
> I didnt know that. Can You elaborate ?  :)

The only reason for the FRA in a dataguard environment is if you would 
like, when you perform a failover, to have the ability to flashback the 
(now) old primary and reinstantiate it as a standby (assuming the hardware 
is useable). If you do not have flashback database set up on your primary 
when you perform a failover you will basically have to recreate a standby 
on your old primary using a backup.

By the way be careful with flashback database on 10.2.0.2 there is a bug 
whereby the logs are not deleted and you can end up filling up the FRA.


> I cant imagine how its suppose to work, never tried to unset 
> archive_log_destination_10 which in FRA configuration
> points to FRA. Moreover as far as I know the only way to backup FRA is 
> via SBT channel .
> > - Consider incrementally updated standby where you make often
> > incremental backups and ship them to standby. It's often the way to go
> > for DW applications but there is no automation with Data Guard.
> Thats great idea I'll investigate that. Looks like some scripts and 
> homegrown solution needed :).

I would think carefully, if you really want to go down the road of rolling 
your own, rather than relying on what you have already paid Oracle for. 
Why try and re-invent the wheel?

That being said, your previous email stated you generated 100GB/hour of 
redo with a bandwidth of 100MB, bandwidth is normally quoted in bits 
rather than bytes, so if those numbers are correct, and you are 
continually generating this quantity of redo, you ain't going to keep your 
standby up-to-date.

jason.

====
Dr. Jason F. Arneil
DBA
Nominet UK
http://jarneil.wordpress.com
====


> 
> Regards.
> Grzegorz
> 
> 
> 
> ----------------------------------------------------------------------  
> Najlepsze zdjecia listopada!
> Zobacz >> http://link.interia.pl/f1ca8
> 
> --
> http://www.freelists.org/webpage/oracle-l
> 
--
http://www.freelists.org/webpage/oracle-l