Re: Larry Ellison comments on Microsoft's benchmark

Unlike many TPC results, DB2 results always publish with mirrored disk. We mirrored the data disks with RAID 1E, and the log disks with RAID 5. DB2 also used a UPS (Uninterrupted Power Supply) - these are all features that raised the price, but made the result more real-world.

Ivana Humpalot wrote:

> Blair,
>
> Can you answer a question that I believe is highly relevant and
> important:
>
> Does Larry Ellison's comments apply to the top TPC-C result (DB2
> on NT)?
>
> In other words, if one of the machines fail, will DB2 still give
> me the right results? Or will queries fail or give wrong answers?
>
> What I want to know is whether the configuration as tested can be
> used in real life without using any additional hardware.
>
> "Blair Kenneth Adamache" <adamache_at_ca.ibm.com> wrote in message
> news:39616BBF.C3CFA30C_at_ca.ibm.com...
> > For what it's worth, the top TPC-C result is now DB2 on NT, another shared
> > nothing database (unlike Microsoft SQL Server, this version of DB2 will
> > allow the partition key to be updated). See:
> > http://www.tpc.org/new_result/ttperf.idc. Between TPC-C and TPC-H
> > (http://www.tpc.org/new_result/h-ttperf.idc) IBM software (DB2) and/or IBM
> > hardware (a mixture of Netfinity, RS/6000 and NUMA-Q) now hold top spots
 for
> > all TPC-C and TPC-H metrics that focus on performance.
> >
> > Serge Rielau wrote:
> >
> > > Finally this thread made to the DB2 newsgroup, eh?
> > >
> > > Here are my 2 (biased) cents:
> > > 1. Microsoft was sued over that benchmark because they violated one of
> > > the rules.
> > > I.e. SQL Server cannot update the column used to partition the view
> > > over the
> > > federated database. The TPC-C benchmark requires updateability of ALL
> > >
> > > columns. It seems like they'll get away with flagging their violation
> > > and a raised
> > > finger.
> > > To be fair I should add that updating of partitioning keys is no
> > > trivial excercise.
> > > 2. The benchmark did not use mirroring. As stated in earlier posts
> > > running such a
> > > beast in a company would be quite - unstable. One has to watch this
> > > when
> > > looking at the price/performance numbers.
> > > 3. Jim Gray said himself that the environment was very hard to set up
> > > and to keep
> > > running through the audit.
> > >
> > > Finally a federated database is not the same as an MPP system like e.g.
> > > DB2 EEE.
> > > In an MPP system the whole query plan gets compiled with MPP in mind and
> > > parts
> > > of the execution get distributed to the participating nodes. The whole
> > > thing is still one database, partitioned tables are still tables and the
> > > integration is VERY tight.
> > > A federated database sits on top of other database systems. Parts of the
> > > query get
> > > shipped (like SQL Servers pass through queries) to the target systems
> > > and the
> > > results get shipped back. On DB2 side this would be Datajoiner or the
> > > new DB2 V7.1 where SQL queries get reverse engineered post optimization
> > > and send to the target systems through public interfaces. The connection
> > > is loose compared to MPP and involves sending the SQL (rather than
> > > "executable sub query plans"). Partitioned tables are represented as
> > > views with all their advantages and disadvantages.
> > >
> > > just my two cents
> > > Serge
> >
Received on Tue Jul 04 2000 - 00:00:00 CDT