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

Partition keys are automatically chosen if you don't choose one explicitly with DDL. DML does not have to change.

Mark Townsend wrote:

> 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 Thu Aug 16 2001 - 15:41:53 CDT