Re: Deadly sins againts database performance/scalability

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1070150069.551425_at_yasure...
> Mark D Powell wrote:
> >
> > You can disagree, but I think your are failing to consider how much
> > real world work is done in batch type processing.
> >
> > -- Mark D Powell --
>
> And I will. I remember the first time I was a Boeing and wrote code that
> did that. Seemed reasonable at the time as I was bringing in gigabytes
> every weekend. But now with UNDO I'd argue just the opposite. Disk is so
> inexpensive

As one who frequently quotes the 'disk space is cheap' mantra, just for laughs, let me state that "proper" disk space is *not* cheap... EMC aren't exactly bargain basement material.

Furthermore, RAM is definitely not cheap, and the more disk space you have, the more blocks there are which need a home in the buffer cache.

So I'm not agreeing or disagreeing with you... just saying things aren't as simple as that, and there are subtleties to be considered.

>it makes no sense not to just assign the equivalent of 1 or
> more drives, often 40+GB to UNDO and let it run to comletion.

Bear in mind the Oracle automatic undo algorithm: the more space you assign to the undo tablespace, the more undo segments you end up acquiring. The more undo segments, the more undo segment header blocks. The more undo segment header blocks, the more Oracle overhead there is to manage the thing. And the more undo blocks in general, the bigger your buffer cache had better be.

The "sense" in automatic undo is that left to its own devices (ie, implemented poorly) it can consume resources at a rate of knots.

Regards
HJR
>
> But your point is valid in a datawarehouse situation. Can we at least
> agree that commits in OLTP loops is almost undoubtedly without merit.
> --
> Daniel Morgan
> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
> damorgan_at_x.washington.edu
> (replace 'x' with a 'u' to reply)
>
Received on Sat Nov 29 2003 - 20:46:26 CST