| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Larry Ellison comments on Microsoft's benchmark
In article <53Ua5.39284$i5.489528_at_news1.frmt1.sfba.home.com>, "Ivana Humpalot" <ivana_humpalot_at_nospam.com> wrote:
After reading this series of appends, I am afraid I have come to a conclusion that you don't really know what you are talking about. Or to be more precise, you may know about Oracle Parallel Server (OPS), but you know very little about shared-nothing parallel databases in general or DB2 (please note the correct spelling for future reference) in particular.
The comments that follow are about DB2 -- I don't have much to say about MS SQL Server since that is not a clustered database implementation and is thus not relevant to a discussion at hand.
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.
>
> Are you asking this question about DB/2, MS SQL Server or Oracle
> Parallel Server?
>
> If the question is about DB/2 or MS SQL Server then the answer is
> your query will fail if it needs data on the failed machine.
>
The query will not fail -- assuming you configured the system for HA scenario, another server in a cluster will take ownership of the data on disks and will respond to a query. A machine may "fail", but the query will not. There may be a temporary outage (i.e. an SQL error message will come back to the client) while the HA recovery takes place (i.e. transaction rollback/roll-forward) but I don't believe it's any different with Oracle OPS which also needs to perform transaction recovery following a server failure.
Don't anybody forget -- Oracle is using "shared disk", but each server in a cluster has it's own buffer pool cache which disappears when the server goes down. To avoid database corruption, Oracle also must take recovery steps.
> If your question is about Oracle Parallel Server then the answer
> is all queries will continue to work, because all machines have
> access to the shared disks. Unlike DB/2 or MS SQL Server, the
> database is not subdivided into smaller databases.
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.
>
> 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.
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).
Thirdly, don't forget that unlike Oracle OPS which doesn't scale to large multi-node clusters, DB2 does scale to very large commodity-priced clusters, so the issue of having a spare box around is not a significant one.
> In the case of Oracle Parallel Server as you add machines to the
> cluster, not only will performance go up, but reliability goes
> up too.
>
So as you add more machines to OPS the reliability goes up? It's too bad then that so far Oracle OPS has not shown ability to scale to large clusters (i.e. beyond 8 nodes).
> 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".
>
> In short, only Oracle has got it right. Oracle's benchmarks are
> relevant in the real world, whereas Microsoft's and IBM's
> benchmarks are laboratory-only benchmarks.
>
>
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
This leaves Oracle, as one of the last remaining proponents of shared-disk clustering, fighting a rear-guard action as it slowly and quietly migrates from its own clustering architecture toward that of its competitors.
Enough said.
Gene Kligerman
P.S. I am an employee of IBM, but the opinion expressed above is my own.
Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Thu Jul 13 2000 - 00:00:00 CDT
 |
 |