RE: db_recovery_file_dest_size

The quota it enforces applies to flashback recovery files and archived redo logs. If you hit the quota and are trying to write an archive log, the error message is the same as if your filesystem was 100% full (but without the OS errors that are also reported), and similar to if the dest became unavailable as in disk failure. You correct in that it can be really irritating, but the parameter is dynamic. If you have 50g freespace available and just want to bypass it, just set db_recovery_dest_size to the size of freespace (or even larger).  

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jason Heinrich Sent: Friday, December 19, 2008 1:40 PM
To: mfontana_at_enkitec.com
Cc: oracle-l_at_freelists.org
Subject: 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