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

On Wed, 15 Aug 2001 09:35:33 -0400, Serge Rielau <srielau_at_ca.ibm.com> wrote:

>Funny thing is: It's not any DBMS vendor's job to define the vocabulary....

Sure. But when talking about two products, if we don't agree on *some* form of terminology we can *both* relate to, we're forever condemned to pee in the wind, both directions. True? :-)

>For all intents and purposes (let's not get into different meanings of an "instance" between
>different DBMS's here) I would suggest that we can settle for a "single view and a single
>product" I.e. the DB Admin should see only on database.
>
>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).

See Mark's reply. I don't have a problem with some limitations in design being imposed when this happens, as opposed to ORACLE's approach, where design is not directly impacted but performance may be in some situations. All I want to do is get a clear picture of the fundamental diffs, so I can help both the UDB and the ORACLE guys when I'm faced with a common environment. Yes, it happens more often than you might think!

>
>I'll happily join in in bashing M$ though :-)
>They are building a federated DBMS when they are running TPC-C.

Is that what they call a dis-jointed DB nowadays? ;-)

>They need to create tables on each node (which would match partitions) and then create a UNION
>ALL view on top of it on each node.

Ay! We had that in V7, didn't last long... *Bad* idea!

>The options of clustering DB2 for high availablily (on top or in constrast to scalability)
>have been described by another person in this thread.

Sure. Those have been available to ORACLE as well for ages. And I'm sure to DB2 as well. Nothing new there. In fact, nowadays we even have competitors to the HACMP concept: Veritas FS is a recent example that springs to mind.

>
>It is widely known that Oracle has a different approach to parallelism (shard disk) than DB2
>UDB, Informix, Teradata (shared nothing). That doesn't make one clustered and the others not.

Sure, I don't have a prob with that.

>
>DB2 leaves you the choice between having the node that went down being replaced by another node
>which participates in active computing (in which case workload goes up for that node which is
>what Larry likes to rub on, while is gets distributed on Oracle (what happens if you have used
>partitioning on Oracle, btw?)) or by an idle node.

OK. Got it. BTW, Larry might like to rub that on, but there are some performance drawbacks too to ORACLE's approach, so he's far from clean on that front. All it needs is the wrong kind of application design and things may well go "clunk". Then it's time to call-in the "expert brigade" (read: their Gold Support Services, at a price of course)...

>Note that with the software available today (e.g. on AIX) your cost for the idle node would be
>1/32 (one failover node dedicated to 32 active ones) of the hardware costs + the clustering
>softare (which you also need for Oracle).

Yeah. With O, that wouldn't be the case. But there are alternatives. In the case of the system I described before, it was quite common for us to turn one of the three nodes into a separate dev/test system. On peak periods (e-o-m) we'd bring it back to cop with the load, then drop it off again to development once the monthly stuff was done. Can be done too with DB2 in the arrangement you described, so there is only a small difference there in methods of operation and design/coding of the thing.

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

Here I disagree. It's all a question of reaching consensus with the sales rep as to how the pricing is handled/scheduled/apportioned. In our case, we had a very good deal to operate as I described. Much cheaper than other options we looked at at the time. Not saying it couldn't be improved on nowadays. Back then, it was a darn good deal.

>
>Two different approaches, both with up and downsides, no question about it.
>Keeps my job interesting.

I'm always baffled at how similar and at the same time how different UDB/DB2 and O really are as products. And how different the two companies are. And yet, nothing is really new in this industry: UNIVAC was doing SMP systems and clusters back in the early 70's when I started. No one cared about it. Then it became important with DEC. Then it went away. Now it's making a comeback. Variety is the spice of life when the ingredients are all the same, eh? ;-)

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