Mark Townsend wrote:
> Serge Rielau wrote:
>
>> *beep* The TPC-C benchmark as employed by Oracle does as little prove
>> that RAC scales as TPC-C does
>> that DB2 + DPF scales in an OLTP environment.
>> The reason being that the app was partitioned (just like the 440k TpmC
>> DB2 + DPF on Win2k TPC-C result was partitioned many moons ago) and
>> the load was explicitly routed for datalocality. This is the
>> contradiction of the RAC premise of NOT having to change the App.
>> TPC-C is no validation for RAC's scalability within the metric not
>> supported by DB2.
>> Just keeping you guys honest :-)
>>
>> Cheers
>> Serge
>>
>
> Serge, in the interest of honesty, why not disclose the rest of it ?
>
> Here's the partitioning statement from the DB2 SMP FDR
>
>> All tables but ITEM were horizontally partitioned into multiple tables.
>> Each (STOCK, CUSTOMER, ORDERS, ORDERLINE) table partition contains
>> data associated with a range of 1600
>> warehouses.
>> Each (WAREHOUSE, DISTRICT, NEWORDER) table partition contains data
>> associated with a range of 32,000
>> warehouses.
>> Each HISTORY table partition contains data associated with a range of
>> 16,000 warehouses.
>> For each partitioned table, a view was created over all table
>> partitions to provide full transparency of data manipulation.
>
>
> So lets see. That's 160 Customer tables, 8 District tables, 16 History
> tables, 8 New Order tables, 160 Order tables, 160 Order_Line tables, 160
> Stock tables, 8 Warehouse tables and 1 Item table. Each with there own
> DDL statements, plus corresponding indexes, constraints etc
>
> Here's the partitioning statement from the Oracle RAC FDR
>
>> Horizontal partitioning was used for history table.
>
>
> So thats 1 Customer table, 1 District table, 1 History table with 16
> range partitions, 1 New Order table, 1 Order table, 1 Order Line table,
> 1 Stock table, 1 Warehouse table and 1 Item table.
>
>
> Which do you think best gets close to a real world scenario ?
>
> And why does the IBM result, which is _NOT_ even on a cluster, require
> significantly more partitioning, than Oracle, which is ?
>
There we go.. and you avoided talking about the app awareness all together.
So from Oracle RAC requires no app changes to scale we are to shades of
grey. The difference is that DB2 never made the claim of being Tide white.
Note that in the SMP scenario the App does not need to be aware.
I see nothing bad about devising a fast physical design.. as long as one
is honest about it and it doesn't infest the app (which it doesn't on
SMP) :-)
Presumable the clustering in CREATE CLUSTER helps as well, right ?
Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Received on Sun Jan 30 2005 - 08:29:20 CST
