Serge Rielau wrote:
> 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
What do you mean by "app awareness"? If you mean with RAC the
application needs to know it is on RAC you are incorrect.
BTW: CREATE CLUSTER has nothing to do with RAC. It relates to the
ability to put rows from multiple tables into the same database
block (page) for performance, not scalability or HA.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)
Received on Sun Jan 30 2005 - 16:25:45 CST
