RE: db_recovery_file_dest_size

This parameter can be very helpful in both very small test systems (where recovery might well be on the same device as / or C:) and in very large shops where there is separation of duties between monitoring and provisioning storage and the dbas actually using storage. In high availability systems it can be part of the soft limits and headroom requirements configured so that automatic alerting takes place without ever reaching it unless the hard limit (actual available acreage in this case) is reached. The number of things that can go wrong in an operating system trapping errors and passing them up the chain when an actual hardware limit is exceeded is much much greater than what can go wrong when a single program recognizes and honors a soft limit.  

In the small test system case where the recovery destination is the same device as the OS (also known as production for some places I've seen), it can be used to prevent going splat at the OS level (which various OS's by type and release handle in more or less annoying manners).  

In case of separation of duties, it can be set lower than the actual head room available so that it remains completely within the ability of the dba group to temporarily correct the problem by setting it higher without having to wait for new storage. The incident (we got closer to full than our service level definition allows) is then trackable and documented, even if the dba group does not have access to the tools to track how full a storage pool is. Further, having to raise it (still within the actual limit of available space), whether manually or automatically may signal the need for a meeting to decide whether it was a notable exception, whether it was an erosion of headroom that is likely to be repeated that can be fixed by operational changes, or whether procurement should be notified to buy more disk.  

It can also be used as a "start purging" trigger or a trigger to start making the "last backup" of the oldest arch files so they may then be purged. The trigger logically would be "We're within x% of the total we want to fill, so it is time to throw away some stuff."  

If this is a debate about the value of soft limits versus hard limits and you prefer hard limits, just set it bigger than you actually have and bump it bigger whenever you add storage acreage to the destination.  

If this is a debate about "why should Oracle handle that, we can handle that so many different ways with other tools?" then it is the same debate as why Oracle still allows multiple members in a log group when "everyone" only runs on multiplexed storage anyway.  

There are probably additional useful ways that db_recovery_file_dest_size can be used, but I hope I've given enough.  

It does seem the parameter should allow some sort of value (-1 anyone?) that maps to "Unlimited" or "Oracle is not responsible for preventing you from attempting to overfill the destination." On the other hand, if there are multiple code trees where the limit is checked that enhancement might tend to destabilize Oracle overall.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael Fontana
Sent: Monday, December 22, 2008 4:18 PM
To: 'Jared Still'; niall.litchfield_at_gmail.com Cc: robertgfreeman_at_yahoo.com; 'Allen, Brandon'; oracle-l_at_freelists.org Subject: RE: db_recovery_file_dest_size      

From: Jared Still [mailto:jkstill_at_gmail.com] Sent: Monday, December 22, 2008 3:13 PM
To: niall.litchfield_at_gmail.com
Cc: robertgfreeman_at_yahoo.com; mfontana_at_enkitec.com; Allen, Brandon; oracle-l_at_freelists.org
Subject: Re: db_recovery_file_dest_size  

>>I wonder how much of this is brought about by the 'one server, one
database' philosophy?  

This is exactly the point I was trying to make in the original post without spelling it out. Thanks for the embellishment, Jared!

>>If that is what the Oracle architects have in mind, it certainly does not
fit reality.  

I think that's exactly how they were thinking, oh say, back in 2002?  

The enforced nature of the parameter (caused by setting db_recovery_file_dest to begin with) is where the problem really lies, IMHO.

If 11.1.8 (or whatever they decide to call the next big thing) would simply make this documentational anachronism optional, I'd be more than satisfied!  

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