RE: db_recovery_file_dest_size

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!      

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