Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Database or store to handle 30 Mb/sec and 40,000 inserts/sec
Mark Townsend wrote:
> Serge Rielau wrote: >
> > > So IBM never recommends UR for DB2 LUW except for situations where users > can tolerate wrong results (i.e data sampling ?).Just like Oracle never recommends bitmap indexes in OLTP.. So _barring_stupidity_ I'd guess that's correct. I can't warrant for 160,000 IGS employees ;-)
> And presumably you would advise MS users to not use UR as well ? Unless they can tolerate the implication. Just like I wouldn't recommend an Oracle customers snapshot isolation if their transaction must be serializable.
> What is the default isolation level for DB2 LUW ?
Cursor stability (aka read committed).
This is also by far the most popular isolation level on DB2.
> What is the default isolation level for SQL Server 2005 ? I have no clue. But apparently I'm on my way to becoming a SS2005 expert in no time in this group. ;-)
>> I find it highly amusing how posters justify isolation levels based on
>> locking behavior.
>> Isolation is semantics, locking is implementation.
>> There are quite viable solutions for READ COMMITTED isolation level
>> which have the exactly same concurrency behavior as Oracle's
>> implementation of Snapshot Isolation.
> > > I'm sorry - but who's implementation of RC is the same as Oracle's MVRC ?And here goes another twist. == Concurrency behavior <> implementation. Not even <> isolation level.
SQL Server 2005, unless i'm gravely mistaken suppors two new twists.
One of them is MVRC, the other is last committed without readers
blocking writers.
The point being made (at least as I understand it) is that SQL Server's
IMPLEMENTATION of MVRC does not scale and is slow for unspecified
reasons and that last committed is a bad isolation level BECAUSE of
readers blocking writers.
So.. is there any interest in bringing the debate back to a technical
discussion?
Obviously I am not trolling for M$. I'm really interested on what folks
perceive as the issue.
Cheers
Serge
-- Serge Rielau DB2 Solutions Development IBM Toronto LabReceived on Mon Feb 20 2006 - 12:55:34 CST