Re: db_recovery_file_dest_size

From: John Thompson <jhthomp_at_gmail.com>
Date: Fri, 19 Dec 2008 13:52:35 -0600
Message-ID: <11d63ad10812191152j3e039a27u1789dd9064571c86@mail.gmail.com>


The parameter is especially handy when using ASM for storage. You can have multiple databases shareing A diskgroup. This parm prevents any one database from using all the storage in that diskgroup.

On Fri, Dec 19, 2008 at 9:59 AM, Michael Fontana <mfontana_at_enkitec.com>wrote:

> This init parameter really peeves me. I've been using it for years, and
> I have read the documentation repeatedly, yet I still have issues with it
> conceptually.
>
>
>
> Why have, what appears to be, a useless, or at best, redundant parameter?
>
>
>
> The size of the file system itself serves as the governor for how big the
> area can grow. There's no way to set it to "unlimited" like you can for a
> storage parameter of a database object.
>
> Certainly, if I was concerned about it growing and encroaching on other
> objects in the file system, I have a design flaw and should build a new file
> system for whatever else is writing there.
>
>
>
> Perhaps it is merely an anachronistic attempt to solve a problem that no
> longer exists?
>
>
>
> Can anyone explain the rationale for this parameter's existence?
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Dec 19 2008 - 13:52:35 CST

Original text of this message