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

DB2 EEE is not as radically shared nothing as Teradata. DB2's approach is like Informix XPS's - somewhat hybrid to allowed shared disk on a large SMP. We might characterize them this way:

Oracle 9i: data is shared amongst nodes (shared data) DB2 EEE, Informix XPS: data is shipped between nodes, but never shared; function is shipped; disk can be shared on large SMP's or disk can be private to nodes on clustered small SMPs (like 4-ways)
Teradata: data and disks are never shared.

Don't thank Mark Townsend for explaining how DB2 works - he's not qualified until he passes the DB2 Certification Exams :)

Nuno Souto wrote:

> 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 - 15:48:19 CDT