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_gmail.com>
Date: 21 Feb 2006 05:14:53 -0800
Message-ID: <1140527693.393842.50030@g43g2000cwa.googlegroups.com>


Again, you don't answer, lets try again...

"inferior implementation"
"Until they are the default, it will remain inferior."

Where is your technical argument? Where is the SQL and DDL to back that up? Also, you didn't say what version you'd used but that not important so long as you post your examples used in SQL Server 2005 which is what we are discussing.

"Writers block readers and readers block writers in SQLServer. There is no
getting around this fundamental issue and because of it SQL Server will always be fundamentally a completely inferior product"

How many more times? PLEASE - that is just not true, note your statement """>>> There is no
getting around this fundamental issue <<<""", well there is, all ANSI SQL standard transaction isolation modes, including READ COMMITTED -->without writers blocking readers<-- have been implemented in SQL Server 2005, apparently you've done some testing on this because you have said its an "inferior implementation" which would imply you have some DDL and SQL to show me .....

"Well, that isn't an application, so, sure, deadlocks can happen."

Exactly, at last !

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

Where is your technical argument? Where is the SQL and DDL to back that up?

We do not follow your religion, and we do not want to break the millions of existing applications that work just fine, that is why it is not the default isolation level - doesn't stop you using it though if you really need it !

> 1) Why would you want to read uncommitted transactions.

See below (original example) - and yes, its transactional

> 2) Why would you want readers to get blocked by writers or writers to
> get blocked by readers.

You don't have to in SQL Server - thats the whole argument, read above where you claim its not possible todo anything else, again, I'll quote you "">>> There is no
getting around this fundamental issue <<<""

Now, give a technical reason or reference where you base these opinions on the current version - SQL Server 2005.

Stop dancing and answer the question.

> 3) Why do you need the read uncommitted transaction isolation leve?

See below (original example) - and yes, its transactional

This is transactional! Do you only do this type of thing with read-only databases in Oracle???

<TWO READ UNCOMMITTED EXAMPLES>

An example of Read Uncommitted would be getting the cardinatlity of a column
in a million row table, you want a value between 0.00 and 1.00 as to uniqueness where unique is 1, this would be used for say the optimiser in
working out a query plan. You are not after a definitive reply from your
dataset but just a roundabout idea of the cardinatlity.

Another example is, depending on how you implement the queue, the statistics
of a call centre - where the business requirement is just an indiciation of
how many callers are waiting, it doesn't need to be exact because its for
the board in the call centre as a motiviator to the call centre staff to
answer calls quicker.
</>

Come on - show me your technical arguments instead of dancing around the issues; show me SQL and DDL that you used in your tests.

Show me the references which leaves you to believe its not possible to have an isolation level where writers don't block readers in SQL Server.

You adjusted your argument and finally agreed you can have deadlocks in Oracle, are you now going to adjust your stance and admit you can have an isolation where writers dont block readers in SQL Server or are you still going to argue the toss? If you do comment - post facts and examples (as asked for) and not waffle rebuttle.

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


Galen Boyer wrote:


> On Tue, 21 Feb 2006, tonyrogerson_at_sqlserverfaq.com wrote:
> > You still haven't answered Serge's question about backing up your
> > claims, here are just some of your quotes from this thread....
> >
> > "inferior implementation" "Writers block readers and readers block
> > writers in SQLServer. There is no getting around this fundamental
> > issue and because of it SQL Server will always be fundamentally a
> > completely inferior product" "Well, that isn't an application, so,
> > sure, deadlocks can happen." "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. "
> >
> > This is what I've taken issue with, lets go back to your quotes and
> > ask you to back up your statements with technical fact.....
> >
> > "inferior implementation"
>
> > What parts of the design are inferior and why? Point to some
> > benchmarks, or at the very least post the SQL you used to test; note:
> > Daniel has not done this when asked.
> >
> > Don't post hear-say or your feeling (probably based on no knowledge).
>
> Writers block readers, needing read uncommitted. That is not hearsae,
> it is from over 2 years of designing and developing on SQLServer during
> 13 years of working on databases. That makes it completely inferior.
> Now you come along and say, SQLServer has now caught up. Then how come
> these wonderful implementations are not the default. Until they are the
> default, it will remain inferior.
>
> > "Writers block readers and readers block writers in SQLServer. There
> > is no getting around this fundamental issue and because of it SQL
> > Server will always be fundamentally a completely inferior product"
> >
> > This is completely un-true which is why I took issue, I am not saying
> > SQL Server is better than Oracle or the other way round, SQL Server
> > has an implementation that is up-to-date with current thinking and
> > technology and is not based on what the current thinking was 20 years
> > ago.
> >
> > Please shown me where it states that SQL Server 2005 blocks readers
> > and there is no getting round this fundemental issue.
> >
> > "Well, that isn't an application, so, sure, deadlocks can happen."
> >
> > With the deadlocks, again, we danced around a bit there until you
> > finely admitted they can happen in Oracle,
>
> I never said they didn't happen, but, as you continue to ignore is that
> that is an application bug, not somethign I need to code against.
> Deadlocks can most definitely happen in Oracle. But, in an application
> that I've written, they are my fault, not Oracle's. Do you get it?
>
> > I guess Oracle should never been used with anything that might send
> > adhoc queries against the database, like, say a reporting application,
> > an application with a dynamic search front end etc...
>
> What? Answer my question about your coding of an application and
> whether you put logic in to handle deadlocks or not, would you please?
>
> If your application that you've written is an adhoc tool, then, yes, you
> should of course handle deadlocks, by politely notifying the user. If
> that was the context of your deadlock handling comments, then we have no
> argument.
> >
> > "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. "
> >
> > The beta program was around 3 years long (alpha to final beta), also,
> > there where 100,000's of developers, dbas etc... who installed and
> > used the beta, actually its probably a lot more, the SQL 2005 Express
> > had around 40,000 downloads in one month tail end of last year; also,
> > there where a lot of significant companies go live with 2005 at rtm,
> > one such one is a major retail bank here in the UK - Nationwide
> > Building Society.
>
> Then why isn't it the default.
>
> Are you ever going to answer my fundamental question? When, in a
> transactional environment, would you ever want to read uncommitted
> transactions?
>
> > Please give me references that back up your 'big issue', aside from
> > Daniel who hasn't backed it up either by posting DDL and SQL he was
> > using (if he ever did).
> >
> > ----
> >
> > As to isolations, SQL Server implements all transaction isolations
> > required by the ANSI standard, I keep asking - does Oracle? -
>
> No it does not support all isolation levels. It does not support read
> uncommitted. Period. That is there for inferior implementations.
>
> > nobody has answered except some ranting dissing the ANSI SQL standard
> > (why am I not suprised there, you guys like to keep it complicated so
> > you can't easily move to another platform)!
>
> LOL!!!
>
> > Just because you have been sucked into the Oracle isolation religion,
> > a religion that was started around 20 or 30 years ago doesn't mean we
> > should follow; I've been developing for 19 years now, started out on
> > the mainframe with DB2 for about 5 years. There are plenty of reasons
> > to use each isolation level
>
> What is the reason for read uncommitted?
>
> > but you will always disagree because you follow doctorine and probably
> > don't have any real rdbms experience aside from Oracle! Whereas I
> > guess SQL Server and DB2 guys implement what the business requires
> > rather than what the Oracle engine wants.
>
> What is the reason for read uncommitted?
>
> > An example of Read Uncommitted would be getting the cardinatlity of a
> > column in a million row table, you want a value between 0.00 and 1.00
> > as to uniqueness where unique is 1, this would be used for say the
> > optimiser in working out a query plan. You are not after a definitive
> > reply from your dataset but just a roundabout idea of the
> > cardinatlity.
>
> Again, we are talking about a transactional environment. What is the
> reason for read uncommitted?
>
> > Another example is, depending on how you implement the queue, the
> > statistics of a call centre - where the business requirement is just
> > an indiciation of how many callers are waiting, it doesn't need to be
> > exact because its for the board in the call centre as a motiviator to
> > the call centre staff to answer calls quicker.
>
> Hm... We are in the middle of a business transaction. Why would I ever
> want to see uncommitted transactions?
>
> > I'm not holding my breath, because you follow doctorine you won't
> > agree with the above but thats your religion rather than sound
> > technical based reasons based around the business requirements.
>
> Hm... Yes, I've put forth one fundamental question and you have not yet
> answered it. I'll try to hold my breath, cause I'm sure you'll still
> respond to the thread but not answer the question.
>
> Now, just so you don't get confused or overwhelmed, here are the three,
> very related questions, so answer anyone of them in the context of a
> transaction.
>
> 1) Why would you want to read uncommitted transactions.
> 2) Why would you want readers to get blocked by writers or writers to
> get blocked by readers.
> 3) Why do you need the read uncommitted transaction isolation leve?
>
> --
> Galen Boyer
Received on Tue Feb 21 2006 - 07:14:53 CST

Original text of this message

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