Re: Deadly sins againts database performance/scalability

Mark D Powell wrote:

> 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 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.
>>
>>But your point is valid in a datawarehouse situation. Can we at least 
>>agree that commits in OLTP loops is almost undoubtedly without merit.

I think we don't.

> The original point was that blanket statements are dangerous

Which is why we don't. Because on this I agree as I've stated.

because
> any one rule may not be suitable for different applications and under
> varying work loads.

And we agree again.

   While I agree there are definite drawbacks to
> committing after updating on a per row basis there are situations
> where doing so is a necessity and guidelines produced by the DBA for
> developers need to allow/account for these situations.

And yet again.

> IMHO -- Mark D Powell --

My point, to repeat myself, was that one should try without commits inside of loops as an initial approach and only commit inside of a loop if as a back-up strategy. Too many times commits within a loop are part of the initial build.

Can we agree to agree? ;-)

-- 
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)