Re: Larry Ellison comments on Microsoft's benchmark

Anecdote (quote from a customer): "Every time Oracle lowers its price, we have to pay more."

See http://www.ioug.org:/ (May, 2000 Instapol1):

Do you feel Oracle's new pricing and Internet sales strategy will make it easier to do business with them?
 (Total Votes: 249)

Yes 30.5%

No 69.5%

Norris wrote:

> "Oracle Radically Simplifies Product Line, Pricing, and Support--Many More
> Options Now Included in Standard Products for No Additional Cost."
>
> http://www.oracle.com/corporate/press/index.html?229558.html
>
> Sun, 23 Jul 2000 15:30:24 -0400 Michael D. Long <lead_dog_at_bellsouth.net> wrote:
> >
> > I read an interview with one of SAP's architects that
> > discussed the move to SQL Server. The principle reason
> > given was that the upper tier of the market was saturated
> > and SAP was moving to price more aggressively for the
> > middle tier market segment.
> >
> > SQL Server was more price competitive (at the time) than
> > Oracle, and allowed SAP to lower the cost of goods sold,
> > which helps in maintaining margin and profitability. A recent
> > change in the licensing fees for SQL Server negates some of
> > the price differential.
> >
> > Another factor is that Oracle is a direct competitor to SAP,
> > which I am sure played heavily in the decision. Especially
> > when you consider that Oracle has gone after and won some
> > large accounts where the SAP implementation was still not
> > complete up to 5 years after initial deployment.
> >
> > --
> > Michael D. Long
> > http://extremedna.homestead.com
> >
> >
> > <rd8246_at_my-deja.com> wrote in message news:8kv0q0$lli$1_at_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.
> >
> >
>
> --
> http://www.cooper.com.hk
Received on Fri Jul 28 2000 - 00:00:00 CDT