RE: db_recovery_file_dest_size
- From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
- To: <jheinrichdba@xxxxxxxxx>, <mfontana@xxxxxxxxxxx>
- Date: Fri, 19 Dec 2008 14:30:57 -0500
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Heinrich
Sent: Friday, December 19, 2008 1:40 PM
To: mfontana@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxx>
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
Other related posts:
