Re: lies damn lies and benchmarks

In article <YOzC8.717$eR3.46772_at_news.uswest.net>, you said (and I quote):
>
> Locks can be configured on Version 7 and SQL Server 2000 to be dynamic
> or to set a hard limit. Locks escalate to a next higher up level
> (row -> page -> table) to reduce the overhead in managing the locks
> and minimize the number of resources.

Again a common problem of SS. Locks do NOT necessarily cause more overhead to be managed when their number increases. Microsoft's implementation of them IS the cause of said overhead, not the locks themselves.

>
> For example, given a table with 1,000,000 rows, would it be better to
> issue a million row level locks or one table lock?

In Oracle, I couldn't care less.

>
> Escalation is appropriate in some circumstances therefore it simply
> cannot be dismissed as a bad thing.

Only when the lock implementation is flawed to start with. Fix that and the problem is eliminated. Which means it can indeed be dismissed.

>
> People should be aware that multiversioning costs resources and this
> is another reason it 'costs' more resources to run Oracle. The nature
> of the beast.

Exactly. I'll trade those resources gladly against having to spend money implementing solutions to them in EVERY single site and application. Because the RDBMS doesn't do the job it should be doing.

>
> Nope, this is incorrect. There's no _need_ to break up transactions,
> perform frequent commits that don't map to business units of work --
> provide an example showing otherwise to disprove me.

I'm quite sure if we pour through the doco and user notes from M$ it will be found. Do you really want to go there?

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam