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: Larry Ellison comments on Microsoft's benchmark

Re: Larry Ellison comments on Microsoft's benchmark

From: <rd8246_at_my-deja.com>
Date: 2000/07/17
Message-ID: <8kv0q0$lli$1@nnrp1.deja.com>

Talkin' it and walkin' it are two different things. Facts are that SAP, PeopleSoft, and other ISVs have abandoned Oracle and SQL Server and picked DB2 UDB for Unix/Linux/NT. Rick

In article <8kug0v$aab151_at_imsp212.netvigator.com>,   Norris <jcheong_at_cooper.com.hk> wrote:
> Thanks, Oracle!
>
> =====================================================================
>
> SQL Server professionals owe Oracle a huge debt of gratitude for two
> reasons. First, if Oracle hadn't been caught red-handed stealing
> garbage (yes, literally) some of you might have gone on denying the
> powerful undercurrent of business competition that has driven a good
> part of the Microsoft antitrust trial. (You can read more about
> Oracle's foray into waste management at
> http://www.msnbc.com/news/426438.asp?0nm=N21D.) Second, and more
> importantly, if not for Oracle's (and other vendors') actions in a
> recent Transaction Processing Performance Council (TPC) vote,
 Microsoft
> might have shipped a potentially crippled version of a powerful new
 SQL
> Server feature code-named Coyote.
> Coyote, or distributed partitioned views, lets customers "scale
 out"
> their servers and build what Microsoft calls a federated database.
> What's a federated database? Think loosely coupled database servers
> linked across multiple SMP boxes. Distributed partitioned views are
> updateable views that exist on different servers combined through the
> UNION keyword.
> By now, you've probably heard that Microsoft recently withdrew the
> record-breaking TPC-C numbers SQL Server 2000 posted last February,
> giving up its claim to "The World's Fastest Database." But don't hang
> your head yet. The TPC-C scores were invalidated because the beta
> version of distributed partitioned views that Microsoft used in the
> audited benchmark didn't support the ability to update primary keys. A
> strict literal reading of Section 1.6.3 of the TPC-C specification
> would indeed invalidate Microsoft's results. But interestingly enough,
> both Oracle and Tandem have published "clustered" benchmarks over the
> past few years--none of which complied with a strict literal reading
 of
> Section 1.6.3. These benchmarks didn't support the ability to update
> primary keys either. (You can download the full TPC-C specification
> from http://www.tpc.org/cspec.html.)
> Whether you consider the invalidation of Microsoft's TPC-C results
> fair or not, the result is great news for SQL Server users. Microsoft
> didn' plan to offer primary key updates through a distributed
> partitioned view in SQL Server 2000' initial release. But in the flush
> of embarrassment about the TPC-C results recall, Microsoft has updated
> SQL Server 2000' code base to fully support primary key updates
 through
> a distributed partitioned view. To be honest, distributed partitioned
> view support without the ability to update a primary key would have
> been very limiting for real-world applications. So thanks, Oracle! We
> wouldn't have this nifty feature without your kind support!
> Does Microsoft plan to republish new TPC-C numbers now that SQL
> Server 2000 is in full compliance with the TPC-C spec? Absolutely. And
> the code change shouldn' significantly affect Microsoft's ability to
> post high TPC-C numbers. Technically, no one can reference the tpmC
> score associated with a TPC-C benchmark until the numbers have been
> officially audited. So I can' say that Microsoft has already rerun the
> test and demonstrated that the new and improved distributed
 partitioned
> view support shows essentially the same performance. Instead, I'll
 just
> say that Microsoft has run a test that is awfully similar to TPC-C
 and
> has had the numbers audited and verified by people who look a lot like
> TPC-C auditors. Microsoft is working aggressively to publish new
> numbers, but $4 million systems with 96 CPUs don't grow on trees.
> Although Microsoft is staying mum on this topic right now, I suspect
 we
> won't see the new numbers for at least a month.
> Next week, I'll cover the impact of IBM's newest TPC-C scores and
> what they mean for SQL Server and the future of database technology.
> The story has a happy ending if you're a committed SQL Server fan.
>
> Brian Moran
> SQL Server Magazine UPDATE News Editor
>
> Wed, 12 Jul 2000 06:16:33 GMT Ivana Humpalot
 <ivana_humpalot_at_nospam.com> wrote:
> > "Brad" <Brad_at_SeeSigIfThere.com> wrote:
> >>
> >> What I want to know is how the system can still be reliable if one
 or
> >> more servers are down. If the data is inaccessible then how can
 any
> >> query be reliable? I can understand if there is some striping
 going on,
> >> but even then if two machines go down all of the data is not
 accessible.
> >> How can the database as a whole be worth hitting if only one of
 twelve
> >> servers is up (as Ivana claimed).
> >
> > Are you asking this question about DB/2, MS SQL Server or Oracle
> > Parallel Server?
> >
> > If the question is about DB/2 or MS SQL Server then the answer is
> > your query will fail if it needs data on the failed machine.
> >
> > If your question is about Oracle Parallel Server then the answer
> > is all queries will continue to work, because all machines have
> > access to the shared disks. Unlike DB/2 or MS SQL Server, the
> > database is not subdivided into smaller databases.
> >
> > In fact, in Oracle Paraller Server, not only will your queries
> > continue to work, the surviving machines will balance the load
> > equally.
> >
> > In the case of DB/2, MS SQL Server etc you are hosed if one of the
> > machines fails because each machine has a unique portion of the
> > database. You can organize the machines into mutual takeover
> > clusters, but this will not work as well as in Oracle Parallel
> > Server because there is no load balancing. The load perviously
> > carried by the failed machine will have to be taken over by a
> > single machine. If that machine is already running at full capacity
> > then you have a big problem because the machine will be overwhelmed
> > and now you have 2 dead machines instead of one. You can also use
> > failover clustering - i.e., have a backup machine for every machine.
> > Obviously this will drive up costs. Also, the backup machine will
> > be idle until the main machine dies, so this is extremely
> > inefficient use of resources.
> >
> > In the case of Oracle Parallel Server as you add machines to the
> > cluster, not only will performance go up, but reliability goes
> > up too.
> >
> > In the case of DB/2 or MS SQL Server, as you add machines to the
> > "cluster", reliability goes DOWN! This is a major flaw. Think
> > twice before adding machines to boost performance, because you
> > are going to get increased downtime. And this ignores downtime
> > due to the fact that in order to add a machine you have to
> > repartition the database.
> >
> > In short, only Oracle has got it right. Oracle's benchmarks are
> > relevant in the real world, whereas Microsoft's and IBM's
> > benchmarks are laboratory-only benchmarks.
> >
> >
> >
>
> --
> http://www.cooper.com.hk
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Jul 17 2000 - 00:00:00 CDT

Original text of this message

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