DA Morgan wrote:
> Galen Boyer wrote:
>
>> On Sun, 12 Feb 2006, tonyrogerson_at_sqlserverfaq.com wrote:
>>
>>> Thanks Mark, yes...
>>>
>>> This gives statement level snapshop...
>>>
>>> ALTER DATABASE Concurrency SET READ_COMMITTED_SNAPSHOT ON
>>>
>>> and/or
>>>
>>> This gives transaction level snapshop...
>>>
>>> ALTER DATABASE Concurrency SET ALLOW_SNAPSHOT_ISOLATION ON
>>>
>>> The later is the transaction versioning that Oracle offers; the former
>>> just gives the last committed value and doesn't block the writer; both
>>> can be in force if necessary.
>>
>>
>>
>> My biggest issue with this is that SQLServer has just implemented this.
>> I have no idea how well it works, and I have no trust that it actually
>> is a solid implementation. Oracle's fundamental architecture, in place
>> since God knows what version, has always supported the fact that writers
>> don't block readers and readers don't block writers. Heck, even as you
>> show, SQLServer tries to implement both sides of the house with
>> different levels. I just don't see how, in such a late release, that
>> anybody is going to believe they got it right, while we are 100% certain
>> Oracle did get that right.
>
>
> From what I've seen in my lab it is a pathetic implementation covering
> up for the inability of the engine's native capability with lots of CPU
> and lots of hard disk writes.
>
> I think they went for the marketing claim ... and to satisfy SAP ...
> rather than actually fixing the underlying weakness in the design of the
> kernel.
SAP? Is that just a guess of yours? If there is one thing I've never
heard SAP ask for it's Snapshot Isolation
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Received on Fri Feb 17 2006 - 10:25:51 CST
