RE: db_recovery_file_dest_size
- From: "Michael Fontana" <mfontana@xxxxxxxxxxx>
- To: "'Crisler, Jon'" <Jon.Crisler@xxxxxxx>, <jheinrichdba@xxxxxxxxx>
- Date: Fri, 19 Dec 2008 14:00:39 -0600 (CST)
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?
It's very easy to add to the file system as the result of a backup blowing
out space, and then neglect to alter this parameter. I am almost tempted
to look at the most recent backup size divided by the size of the database
to estimate how much space my next backup would need in a script before it
runs and report the shortage rather than have the job run for nothing. I
know oracle will sometimes already remove unneeded files only when the
area fills up, but I figure that's got to take time.
Try to imagine if oracle had a whacky parameter like this for everything
else. How would you set a db_create_files_dest_size, an
utl_file_dir_size, or a core_dump_dest_size?
Those, of course do not exist, I know, and would be rediculously to
monitor and enforce.
The flash_recovery_area is even more dynamic and hard to predict, so why
force me to estimate it's size in advance?
When you consider the fact I can give it some ridiculously large made-up
number, it's actual purpose is even harder to explain!
Other related posts:
