Re: Larry Ellison comments on Microsoft's benchmark

<kligermn_at_ca.ibm.com> wrote in message:
>
> The basic premise of the underlying question is whether you
> can configure DB2 shared-nothing database in a High Availability
> configuration. The answer is YES, using a variety of clustering
> options such as HACMP on AIX, Sun Cluster on Solaris, MSCS
> on Windows, etc.

My question is this: Does DB2 support load-balanced / parallel clustering, or only failover clustering. From previous posts on this thread I know that with DB2 on MSCS, you only have two options for HA: Either have a mutual takeover situation, or have failover. There are defects with both. In a mutual failover situation the entire load on the failed machine has to be taken over by just one machine. If that machine is already heavily loaded then DOUBLING the load on that machine will likely overwhelm that machine, potentially killing that machine too. In a failover situation you double the number of machines which increases costs, and you get poor utilization of resources because half of the machines are idle.

Compare this to Oracle Parallel Server. In OPS, if one machine dies the load on that machine is DISTRIBUTED on the remaining machines. So the load on surviving machines only increases slightly. There is also 100% utilization of resources, because no machine is idle.

> DB2 implementation (unlike MS SQL Server) is a single database.
> And as I mentioned above, both Oracle OPS and DB2 will continue
> to work following data recovery processing.

But DB2 cannot continue without the failed cluster node (i.e., pair of machines in MSCS) whereas Oracle can continue without the failed machines.

> > In fact, in Oracle Paraller Server, not only will your queries
> > continue to work, the surviving machines will balance the load
> > equally.
> >
> > In the case of DB/2, MS SQL Server etc you are hosed if one of the
> > machines fails because each machine has a unique portion of the
> > database. You can organize the machines into mutual takeover
> > clusters, but this will not work as well as in Oracle Parallel
> > Server because there is no load balancing. The load perviously
> > carried by the failed machine will have to be taken over by a
> > single machine. If that machine is already running at full capacity
> > then you have a big problem because the machine will be overwhelmed
> > and now you have 2 dead machines instead of one. You can also use
> > failover clustering - i.e., have a backup machine for every machine.
> > Obviously this will drive up costs. Also, the backup machine will
> > be idle until the main machine dies, so this is extremely
> > inefficient use of resources.
> >
>
> Aha! Finally something meaningful to talk about. The clustering
> description is almost accurate, although some important aspects
> are being ignored.
>
> First of all, if Oracle OPS is "already running at full capacity"
> then it will have just as big a problem.

No, in Oracle OPS, the machines will be only slightly overloaded (assuming there are many machines in the cluster) whereas in DB2 and MS SQL Server the load is DOUBLED (regardless of how many machines you have in the MSCS cluster). Which is more likely to cause a failure?

> Secondly, using a backup machine for every machine would
> double the server cost... but this ignores the fact that
> you can configure clusters not in pairs
> but much larger configurations. In the case of HACMP on AIX,
> up to 32-way clusters are supported, which means that you could
> have only 1 idle machine (less than 5% of server costs, a fraction
> of the overall system cost).

I was talking about MSCS clusters, which is what was used in the top TPC-C benchmark.

But even with DB2 on 32-way clusters, if you only have 1 idle machine, if 2 machines fail then the load on at least machine will double, which could lead to a total system failure. In Oracle Parallel Server, 16 machines will have to die before the load on one machine doubles.

> > In the case of DB/2 or MS SQL Server, as you add machines to the
> > "cluster", reliability goes DOWN! This is a major flaw. Think
> > twice before adding machines to boost performance, because you
> > are going to get increased downtime. And this ignores downtime
> > due to the fact that in order to add a machine you have to
> > repartition the database.
>
> Nonsense. The bigger worry is the use of large expensive servers
> featured in Oracle clusters because of OPS' inability to scale
> across clusters. This forces you to buy a few large monolithic
> machines instead of a larger number of much less expensive ones.
> And if one of those expensive large machines does go down, then
> it is not practical to just "get another box".

I don't think what you are saying is true. Oracle supports massively parallel processing. This is how Oracle implemented Video-On-Demand on nCUBE's MPP machines.

In a cluster, as you add machines reliabilty is supposed to go UP, not down. In Oracle Parallel Server, as you add machines reliability goes UP. In DB2 MSCS clusters, as you add machines reliability goes DOWN. Are you saying this is not a concern when adding machines?

> Hallelujah! I have seen the light! Rather than expressing a
> grandiose opinion of my own, let me cite a more objective reference:
>
> Timothy Dyck, e-Week Magazine:
> http://www.zdnet.com/eweek/stories/general/0,11011,2573101,00.html

I have never read a more biased story. It contains outright lies too. For example, it offers Oracle's "cache fusion" as proof that Oracle is moving towards shared nothing architecture. Nothing could be farther from the truth. Search for "cache fusion" on Oracle's web site. Cache fusion has NOTHING to do with shared nothing architecture, and EVERYTHING to do with shared disk architecture. Oracle's biggest strength compared to DB2 and MS SQL Server is shared disk clustering as implemented in Oracle Parallel Server. Received on Fri Jul 14 2000 - 00:00:00 CDT