Re: Deadly sins againts database performance/scalability

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1070228128.612343_at_yasure>...
> 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 still disagree.
>
> 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? ;-)

I'm not sure you've agreed with Mark's statement, which statement implies that you should not try it first because you must take into account the overall functioning of the system, which is often less pure OLTP than one would assume from your repetition.

I've seen it over and over again, especially with Mark's examples of MRP and ERP systems, they just aren't pure. Worse, the data warehouse project that could perhaps partly purify them drags on unfinished until they get news that, for example, now we can have multiple block sizes, so why _not_ have everything in one giant instance for up-to-the-second data? :-O

Time for an Oracle Purity test! :-)

jg

--
@home.com is bogus.
Death of Moore's Law, news at 11
http://www.msnbc.com/news/999894.asp?cp1=1