Re: db_recovery_file_dest_size
- From: "Jared Still" <jkstill@xxxxxxxxx>
- To: Brandon.Allen@xxxxxxxxxxx
- Date: Fri, 19 Dec 2008 14:05:56 -0800
On Fri, Dec 19, 2008 at 12:35 PM, Allen, Brandon
<Brandon.Allen@xxxxxxxxxxx>wrote:
> I forgot to mention another option – just don't use the flash recovery
> area at all.
>
>
That's my personal recommendation, even if use of FRA is 'strongly
recommended'.
The old fashioned method works quite well for multiple databases.
I dump all archive logs to the same filesystem from several databases on one
linux server.
The SAN easily handles the IO, and there are no artificial limits placed on
the
consumption of space by database parameters, or by putting archive logs
in different filesytems for different databases.
The only good reason I can think of for separating archive IO to separate
filesystems
is to improve write performance for archives, and even at that, it is a
questionable
practice on SANS anymore.
That's my opinion anyway, one that works pretty well in our environment.
YMMV
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
>
>
>
>
> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Michael Fontana
>
>
>
> What is really bizarre about this parameter is exactly what you describe,
> Jon. It has no real bearing on reality. I can set it to some mythical
> number much higher than the actual file system, and I can set it to 80mg
> with a 20tb database.
>
>
>
> So what's the point of it?
>
>
>
> ------------------------------
> 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.
>
Other related posts:
