Re: tx isolation

From: Pablo Sanchez <pablo_at_dev.null>
Date: Mon, 02 Dec 2002 21:42:46 GMT
Message-ID: <Xns92D895AAEF976pingottpingottbah@209.242.64.107>

"Brian E Dick" <bdick_at_cox.net> wrote in
news:DgQG9.65177$wc2.2793221_at_news2.east.cox.net:

>> > By side-stepping the locking issue, this benchmark gives the SQL
>> > Server locking model an unfair advantage over the Oracle locking
>> > model. In a real world "shared something" or "shared mostly"
>> > application, Oracle shines.
>>
>> I believe this assertion is incorrect because the first statement was
>> wrong that the benchmark is a highly partitionable problem.  The
>> payment transaction clearly shows that we need to coordinate the
>> updates to the affected tables among the clients.

>
> But the benchmark IS highly partitionable, and that's how the vendors
> are blowing the TPM numbers so high. When IBM first crossed the 500K TPM
> mark, they did it by clustering many UDB machines and using over 7000
> hard drives.

Take a look at the reports, there's a clustered and a non-clustered result set. Looking at the non-clustered, we have a single system image. We need to have many disk drives to simply drive the benchmark. That's a given. Is it a reality to implement? Not for most folks.

>> > Multiversioning resolves a difficult problem, resource
>> > contention, and allows the developer to move on to bigger and
>> > tougher problems.
>>
>> There's nothing difficult about working with a locking model.

>
> Why does SQL Server promote optimistic locking by implementing
> timestamps? Why does Oracle do multiversioning? Why do you index your
> foreign key columns? Why do you carefully use "FOR UPDATE"? Why do you
> carefully hold open transactions while waiting for user interaction? Why
> ...?
>
> Because locking will kill performance if it is not done right. And too
> often it is not done right.

I disagree with that statement ... it's subjective statement.

FWIW, in my experience I see way more other issues than 'locking not done right' ... for instance row at a time processing instead of set based processing, no use of sproc's. I can't recall the last time I saw an issue with locking.

-- 
Pablo Sanchez, High-Performance Database Engineering
http://www.hpdbe.com

Received on Mon Dec 02 2002 - 15:42:46 CST