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

On Thu, 16 Aug 2001 03:00:28 GMT, Mark Townsend <markbtownsend_at_home.com> wrote:

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

I was a bit sneaky in the wording of my request there, Mark. I must apologize to Serge as well, as that was a bit of a trap. I have some familiarity with what you just described from reading quite a few UDB/DB2 books and "manuels". What you point out is a problem in my view, although it's not an insurmountable wall. Requires more work from the design viewpoint. I don't have to cope with this particular problem in ORACLE, but I have to adress other problems that result from their specific approach. 6 of one half a dozen of the other, I suppose.

Some people might prefer IBM's solution. As a designer I prefer ORACLE's, but that's a personal thing. I don't think anyone can make a case for one of them being superior or not. At least not at the current level of both products. I believe 9i has some inbuilt technology that will solve concerns I have with ORACLE's approach, but I haven't yet seen proof of it (and Larry's word is not enough for me...).

>* 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.

I call that vertical partitioning. As opposed to sales date, which I call horizontal. Terminology. Vertical partitioning requires database design changes, while horizontal doesn't. Shared-nothing architectures will always suffer from this problem.

>* 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)

Yes, this is a real problem. There is no easy solution yet. Not because needing replication is bad, but because replication itself poses many other problems.

>* 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

Yes, another problem. This is also common to M$'s approach, with what I called the "dis-jointed" database for lack of a better term.

>
>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.
>

And yet, we still have limitations in ORACLE. There has been a lot of work done in 9i to reduce block-pinging between cluster nodes so heavy concurrent update is not impacted. This used to be a real problem back in V6 and V7 clustering with ORACLE. Got much better with V8 and we're all told it's gone with 9i (jury still out until real-life cases start to roll-in, though).

Thanks a lot for your input. It certainly helped confirm many concepts I had about how UDB/DB2 works in various environments.

All I can say as a conclusion is that the more we know about other products, the better equiped we are to solve problems with the ones we're asked to use.

Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam Received on Thu Aug 16 2001 - 08:24:25 CDT