Serge Rielau wrote:
> 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
What any and all financial systems require is the ability to produce a
result set consistent to a point-in-time ... preferably without locking
tables. Something impossible to do with previous versions of SQL Server.
--
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)
Received on Fri Feb 17 2006 - 10:32:29 CST