Re: Space wasted because of automatic undo management

On Fri, 01 Apr 2005 20:56:35 +0000, Mark Bole interested us by writing:

> I couldn't agree more with the arguments in favor of adding more disk
> space in this situation. However I wish folks would stop needlessly
> weakening the arguments by citing retail $/GB numbers for adding disk
> storage as if they comprised the total economic cost.
>
> For every disk added to production, frequently the same amount (or more)
> of disk must be added to test, development, etc. Then there's the
> increased cost for backup retention, online standby, and hot spares to
> match the increase in primary storage. Power supply, rack space, and so
> one are not free. And I've seen too many examples first-hand of
> administrators who incur labor costs ten times greater than the cost of
> the disks just trying to configure and integrate them into a running
> system, because it's not something they do often enough to be good at it.
>
> -Mark Bole

Good points. And ones that I had not fully been taking into account. Changes the economics a bit, but still worth investigating.

My experience indicates that organizations that are concerned about cost of disk are not likely to have a test, dev or other ancilliary systems as you mention.

However, if the operation is that close to tipping that they need a new frame or new power supplies, new rack space, etc., then they have a planning issue and the undo/redo space management is a small-potatoes issue in the larger picture. (Yes-but micro-managers refuse to look at the larger picture, in this 'do it now, fix it later' world.)

I'd also submit that DBAs and SAs who don't handle that kind of thing often should swallow a bit of pride and suggest to management that the cost of adding and configuring disk is such that for an extra modest fee they could hire a consultant to do so, generally fixed price and with a guarantee. (Can we say Fear Factor? <g>) (Related, how many hours have DBAs, developers, etc. wasted - out of pride - trying to debug things instead of turning for help.)

So the answer still seems to be - do the analysis properly. With the [valid] points indicated in OP, don't exclude adding disks, and don't ignore time and cost of manual management as well. Also add in the potential cost of crisis during DBA's vacation, or the cost of not 'allowing' the one DBA to go on vacation. Etc. Etc. Etc. (redundantly)

-- 
Hans Forbrich                           
Canada-wide Oracle training and consulting
mailto: Fuzzy.GreyBeard_at_gmail.com   
*** I no longer assist with top-posted newsgroup queries ***