Re: Larry Ellison comments on Microsoft's benchmark

From: Norris <jcheong_at_cooper.com.hk>
Date: 2000/07/17
Message-ID: <8kug0v$aab151@imsp212.netvigator.com>

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

Received on Mon Jul 17 2000 - 00:00:00 CDT