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: Serge Rielau <srielau_at_ca.ibm.com>
Date: Fri, 17 Feb 2006 13:20:59 -0500
Message-ID: <45migfF7ikclU1@individual.net>


DA Morgan wrote:

> 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.
That's what timestamps are there for. You rarely need to see the whole database in snapshot mode. If you want to sum the POS data up for the day a simple WHERE clause will do.
To solve concurency issues READ COMMITTED IMHO is plenty good. Anything beyond that is 99% religion, 1% actual requirement.

Cheers
Serge

-- 
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Received on Fri Feb 17 2006 - 12:20:59 CST

Original text of this message

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