"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
