Re: db_recovery_file_dest_size

db_recovery_dest_size is intended to be a "quota" to limit the amount of space the database can consume for recovery files. I think the idea is if you have multiple databases, you can give each one a slice of the filesystem, and you don't have to worry about one database's runaway process generating so many archive log files that all the databases run out of space. Or something like that.

Of course, you need to make sure you actually give the database enough space to store all the recovery files you'll need. And you could avoid the scenario above by giving each database its own filesystem for these files, which is probably a good idea anyway. I agree that there should be an "unlimited" value to tell Oracle to just use all available space on the filesystem, if that's what it's dedicated for.

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?
>
>
>
>
>

-- 
Jason Heinrich

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