Re: Database or store to handle 30 Mb/sec and 40,000 inserts/sec

From: DA Morgan <damorgan_at_psoug.org>
Date: Fri, 17 Feb 2006 07:33:38 -0800
Message-ID: <1140190409.606700@jetspin.drizzle.com>

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.

-- 
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)

Received on Fri Feb 17 2006 - 09:33:38 CST