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: Sat, 18 Feb 2006 16:09:24 -0000
Message-ID: <dt7gr0$3gb$1$830fa7a5@news.demon.co.uk>


> How does this lead
> credence to the fact the SQLServer's concurrency model is somehow on par
> with Oracle's?

I didn't realise I was comparing, I thought I was pointing out Mark Townsend floors in what he stated that Oracle takes care of everything - well it doesn't! You still as a developer need to code for concurrency, deadlocks etc... so trying to flower it up into some magical beast is laughable.

Do a google on oracle and deadlock and there is tons of stuff so don't try and pull wool over my eyes. You do get deadlocks in Oracle and the reasons give in the articles I've read are exactly the same reasons we get deadlocks in SQL Server.

I don't understand why you are so touchy on this subject....

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


"Galen Boyer" <galen_boyer_at_yahoo.com> wrote in message 
news:uu0awh7xq.fsf_at_rcn.com...

> On Sat, 18 Feb 2006, tonyrogerson_at_sqlserverfaq.com wrote:
>>> This one of the differences between Oracle and SQLServer. With
>>> Oracle, a coder does not have to be _as_ aware as to how to mitigate
>>> any limitations of the database server. They can do what they are
>>> good at - write business code. Let the database sort out
>>> transactions, isolation, concurrency problems etc.
>>
>> Having coded using both SQL Server and Oracle, all though the Oracle
>> was version 7 or whatever was out in 1993(ish) and Oracle Glue I can
>> tell you that the coder does need to worry about such things.
>>
>> The majority of applications use the default locking behaviour in SQL
>> Server and have NO problems, the coder doesn't need to change the
>> isolation level, mind you - its good to have an understanding of the
>> ANSI standard isolation levels; depending on your application you
>> might need SERIALIZABLE. But that's an ANSI thing, not SQL Server. SQL
>> Server does make it easy to change locking behaviour on the fly per
>> connection with a simple SET statement.
>>
>>> Coders need to know how to write business code, and also how to write
>>> this code to avoid isolation problems, deadlocks etc.
>>
>> Please, you are not trying to tell me you don't get deadlocks in
>> Oracle.
>
> You only get a deadlock in Oracle if your application is coded with a
> bug. In SQLServer, you can get deadlocks with completely bug-free code
> and there is nothing the application can do about it but deal with the
> deadlock with reactionary application hoop jumping. With Oracle, you
> can step back and rearchitect the buggy pieces of the application so the
> deadlock doesn't happen. You don't check if a deadlock happened and
> then react to that situation, which you do have to do with SQLServer,
> instead, with Oracle, you fix your code so you don't have the deadlock
> happen in the first place.
>
>
>> Deadlocks and concurrency are common traits to any database system and
>> they need to be coded for in the application.
>>
>> The application needs to cater for when a deadlock occurs, do they
>> re-try or fail.
>>
>> The application needs to cater for concurrency, the row you've just
>> modified on your disconnected browser windows - when the user clicks
>> update, can I guarentee the row hasn't been modified by another user,
>> please don't insult my intelligence by telling me the database deals
>> with that, it might do in a batch of SQL running in a transaction -
>
> Thats correct, it does.
>
>> but in a disconnected browser model - i don't think so.
>
> In a model where you get a row, leave the database, do something with it
> and come back to the database? Of course Oracle doesn't "handle" that.
> The client's work was done outside of the database. How does this lead
> credence to the fact the SQLServer's concurrency model is somehow on par
> with Oracle's?
>
> --
> Galen Boyer
Received on Sat Feb 18 2006 - 10:09:24 CST

Original text of this message

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