Re: Why doesn't Oracle care about Linux as IBM does?

in article 3B7A7AA4.2BD70DE8_at_ca.ibm.com, Serge Rielau at srielau_at_ca.ibm.com wrote on 8/15/01 6:35 AM:

> one create database command,
> one create table command,
> one load command to load data into a table
> ....
> In short no differences in DML or DDL required compared to non clustered.
> No difference in transaction processing compared to non clustered.
> No awareness of the application of where it is connected to (or might be
> migrated to on the
> fly).
>
> Yes, DB2 supports this since PE days (before DB2 V5).

Hmm - well, time to come out and play. I think we agree on the definition - basically the clustering of the database should be transparent to the application. So far so good.

But we will have to agree to disagree that DB2/UDB supports clustering without changes to the DML or DDL. AFAIK, IBM EEE requires

• Data to partitioned - requiring the addition of a partition key - resulting in extensive DDL changes of many tables and indexes. In some cases, the ability to use secondary indexes is also lost, and constraint checking across a table can also become cumbersome.
• Co-location of commonly joined tables on the same node to avoid cross-node joins and data shipping - imposing a design limitation on the physical schema and data placement. For instance, sales data may need to be partitioned on product id simply to manage data placement, rather than on sales date, which is a more useful partitioning scheme for data management (archiving etc), and query optimization.
• Physical replication of tables that cannot be partitioned (i.e a node specific table name periofically refreshed from the data in a 'master' table) - typically this apporach is limited to read only tables, or tables that can bare some staleness in their data, due to the cost of a 2 phase commit across two or more tables on two or more nodes (and this cost increases exponentially as more and more nodes are added to the cluster)
• To optimise transaction shipping (called local bypass), the application often needs to be changed to look up the partition map in oder to route the right transcation to the right node. The same approach is required for data load etc, and backup/restore procedures will also need to be adapted to become node specific

The reality is is that IBM EEE is designed specifically for read-intensive environments such as data warehouses and data marts where these types of speed of light issues can be resolved more easily than in a strict OLTP environment - the same basic approach as Teradata. Using EEE for OLTP requires some significant hoops to be jumped through. And IBM's chance of persuading any third party application vendor to build their apps to use IBM's view of clustering is simply not going to happen - as all the 'required' EEE changes are proprietary to IBM.

> This seems like a good bargain considering that you can (and customers do)
> scale out a lot
> higher in return compared to being limited by the clustering software which
> Oracle needs to
> support shared disk on top of the overhead of the lock manager.

The speed of light issues of using a cluster are there - TANSTAAFL - the 'cost' of managing transcations across more than one machine can simply not be avoided. IBM's UDB approach is to require the application developer and DBA to constrain the optimal design of the application to mitigate these issues, limiting the type of applications that can take advantage of a cluster. Oracle's approach (and also IBMs on the Mainframe) is to use some smart software to make mitigation of these issues as transparent as possible to the application, enabling clustering to be used for a wider range of application types. Received on Wed Aug 15 2001 - 22:00:28 CDT