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!

Other related posts: