Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Db2, Oracle, SQL Server

Re: Db2, Oracle, SQL Server

From: Serge Rielau <srielau_at_ca.ibm.com>
Date: Fri, 11 Feb 2005 08:03:20 -0500
Message-ID: <373onnF57734gU1@individual.net>


Noons wrote:
> Serge Rielau wrote:
>
>

>>I don't kno whwat the latter means, and I have in detail talked about

>
>
>>the first point. It is irrelevant whether DB2 requires all the nodes

>
> up
>
>>or not as long as a node can fail over similarly quick as it takes

>
> e.g.
>
>>RAC to evict a node (which is not free!)

>
>
> Not really, Serge. Note the TPC-C detailed program description
> for DB2 and the SELECT statements used to pick data off the
> partitioned tables. And this page:
> http://www.tpc.org/information/sessions/sigmod/sld014.htm
>
> See how different the statements are from the "transparency"
> bit? When "partitioning" requires one to code FROM with
> parameters that define which partition you want to go to
> (because the CBO is so brain-damaged it can't figure that out
> for you), you got a serious problem maitaining "transparency"...
What are you talking about? You can access all the data in DB2 from any node. Many moons ago DB2 had a 440k TpmC results on a windows cluster and it absolutely complied with the slide quotes above. (including updating partitioning keys etc, etc). Does it makes sense to connect (!) to the node with the data if you know before hand?
Yes, absolutely. Just like it makes sense in a RAC cluster to avoid thrashing of pages between the nodes.

> And what happens in a cluster if the partition you wanted
> is on the node that you just offlined?
 > Last time I looked,
> RAC keeps operating blissfully smooth.
Is that what you call the complete outage while remastering the ownership of pages?

> I can't say the same
> for a SELECT statement that has as a parameter the partition
> you want to access...
> Transparency is completely out the window ages ago, anyways.
Just presuming you were right with the select (which I challenge) Why would the node stay offline? This is exactly what I was talking about. You have to kiss goodbye to the notion that nodes go down and stay down. We have customers doing node failover in < 20 sec. Evicting a node in RAC is in the same ballpark. Different approach same outcome.
If it's a software problem db2start on the same physical node. If the machien is dead. db2start on a different machine. HACMP does that just fine.

Cheers
Serge

-- 
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Received on Fri Feb 11 2005 - 07:03:20 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US