RE: db_recovery_file_dest_size
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <mfontana@xxxxxxxxxxx>, "'Jared Still'" <jkstill@xxxxxxxxx>, <niall.litchfield@xxxxxxxxx>
- Date: Tue, 30 Dec 2008 08:54:04 -0500
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Michael Fontana
Sent: Monday, December 22, 2008 4:18 PM
To: 'Jared Still'; niall.litchfield@xxxxxxxxx
Cc: robertgfreeman@xxxxxxxxx; 'Allen, Brandon'; oracle-l@xxxxxxxxxxxxx
Subject: RE: db_recovery_file_dest_size
_____
From: Jared Still [mailto:jkstill@xxxxxxxxx]
Sent: Monday, December 22, 2008 3:13 PM
To: niall.litchfield@xxxxxxxxx
Cc: robertgfreeman@xxxxxxxxx; mfontana@xxxxxxxxxxx; Allen, Brandon;
oracle-l@xxxxxxxxxxxxx
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!
Other related posts:
