Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Database or store to handle 30 Mb/sec and 40,000 inserts/sec

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

From: Tony Rogerson <tonyrogerson_at_sqlserverfaq.com>
Date: Fri, 17 Feb 2006 17:11:33 -0000
Message-ID: <dt503h$cd4$1$8302bc10@news.demon.co.uk>


> 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.

It certainly has a reliance on tempdb, but if the transactions are short you won't get disk activity because it will be done in cache.

Does work though and scales.

I'd be interested to see the SQL and schema you used on your tests - if you can send it me that would be great.

>
> 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.

Its allows easier migration from Oracle into SQL Server.

I don't see a big uptake in using the snapshot isolation feature to be honest, the read committed snapshot is useful for people who have had to resort to using read uncommitted in the past.

-- 
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials


"DA Morgan" <damorgan_at_psoug.org> wrote in message 
news:1140190409.606700_at_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 - 11:11:33 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US