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: tough choices

Re: tough choices

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Sat, 19 Jun 2004 11:59:42 -0700
Message-ID: <1087671606.434867@yasure>


Serge Rielau wrote:

> Daniel Morgan wrote:
> <snip>
>
> No it isn't. A node in RAC can die, a DB2 Partition can die. Lets assume
> both with the same likelyhood (let's put code quality aside for the sake
> of the argument..)
> You have to willing (well you don't ahve to but it would be open mided)
> to concede that restarting the failed DB2 partition (on a different box)
> is an alternative to the Oracle RAC approach of redistributing teh work
> across the remaining RAC nodes.
> I don't ask you to say whether it's better or not, I just ask you to
> consider it an alternative approach to solve the same problem.

Please correct me if you think I am incorrect. But losing a single node with RAC can not deprive users of access to data. The system continues to run with no effect other than the loss of a few CPU's and their associated RAM.

With DB2 I could lose a node and either lose access to some of the data or, worst case, lose the entire database application.

>>>>> 2. The time it takes to get the partition back into the game 
>>>>> compared to  the failover work a RAC cluster has to do (such as 
>>>>> remastering locks). 
>>>>
>>>> In my tests that is less than one second. Far to small with RAC to 
>>>> be of
>>>> concern to anyone.
>>
>> Even Oracle's cover-your-a.. marketing talk says 3 seconds. So it really
>> is inconsequential.

>
> OK, so recussicating the failed DB2 partition in 3 seconds would then
> alos fall under inconsequential. And given that most connectiosn to
> other partitions may not even feel that the DB2 partition is down
> (because they don't talk to it) then maybe a few more seconds could be
> granted as acceptable.

Provided it is not the instance owning machine? Lose that, and as I understand it, you are toast.

To quote the IBM doc linked below: "As indicated earlier, the DB2 Instance owning machine in a DPF environment is the one whose associated disk physically stores the instance home directory."

Those more familiar with Oracle might want to check out: http://www-106.ibm.com/developerworks/db2/library/techarticle/dm-0403chong/index.html to better understand what DPF is.

>>>>> E.g. one can oversize the number of partitions per physical node. 
>>>>
>>>> Which equates to what in Oracle?
>>>
>>> Does it have to equate to anything on Oracle?
>>> I just describe a DB2 + DPF setup. 
>>
>> No. I was trying to determine if there was an equivalency. Often the way
>> each vendor uses/misuses words means the same thing exists but appears
>> to be different. Or something doesn't exist but appears to.

>
> I think the equivalency would be to run an 15 Node RAC on 3 boxes (on
> LAPRs perhaps).

15 nodes would be 15 boxes with RAC.

> If more resources are needed you get 2 more boxes and move 2 nodes from
> each box over to the two new boxes.
> The number of nodes stayed the same, but you gained 66% more horsepower.
> I doubt that would make much sense with the RAC architecture, but it
> makes a lot of sense for DB2's.

I agree.

>> I wasn't aware of DPF. 

>
> Uhm.. but's what half our discussion in past were about :-(

C'est dommage. I am here to learn too.

>> Correct me if I am wrong ... but it seems DPF
>> is an extra cost add-in only available on ESE systems with that some
>> functionality only works on AIX. One question ... is it supported by the
>> optimizer?

>
> To the best of my knowledge DPF is offered on all supported platforms of
> DB2 for LUW.

Not according to:
http://www.developer.ibm.com/tech/faq/individual?oid=2:82779

  The optimizer is very aware of DPF. An important job is to
> make sure the function and the data meet in the right place.
> So only minimal data needs to cross the wire.

Does that agree with the colorful diagram on the first link, above?

> > There is also, from what I can see a master instance which,
>

>> if it goes down takes down, the entire thing down with it. Overall not
>> a very pretty picture. 

>
> Not quite true, but not totally wrong either.
> The coordinator is the DB2 Partition that a client connects to. Each
> partition serves as coordinator. There is no master database partition.

That does not agree with the statement from the IBM quoted above with respect to there being an "instance owning machine." How do you survive without access to the instance owning directory?

> However, the DB2 catalogs today reside on one specific partition.
> So, if that partition came down and a local coordinator needed
> information which is not in it's cache (to compile a new statement
> referencing e.g. a previously unheard table) then that would be bad.

Is that what I have refered to above?

> Most customers I know using DB2 + DPF therefore do not allow connections
> to the catalog partition. It is dedicated to serve meta data.
>

>> And providing functionality available in Oracle
>> at no aditional cost, on all operating systems, and without the
>> liability of one node being capable of bringing down the entire cluster.

>
> OK, now we are talking licensing. I know neither Oracle nor DB2
> licensing well enough to comment. I doubt RAC is free for Oracle's
> enterprice license, though.

Nothing is free. But RAC is now part of standard edition and up to 4 procs is free. I don't know the latest licensing for Enterprise Edition but it would, by necessity, need to be more generous given the higher cost.

>>> The more RAC nodes you have the more likely it is that one of these 
>>> Dell boxes gets sick.
>>
>> But if it gets sick nothing changes.
>>
>>> Oracle RAC can fail over and not turn the sick box into a failed system. 
>>
>> Not in my experience unless I am misunderstanding what you mean by using
>> the highly technical term ... "sick."  ;-)

>
> Misunderstanding. Its the whole point of RAC to fail over (in contrast
> to simply fail)

But what causes it to fail over ... is in fact going to kill any connections. So I'm not sure what the issue is you are speaking of.

>> I've now had a chance to read all of the DPF documentation (well at
>> least a lot of it) available on the net. I am far from impressed.

>
> You are a fast reader I must say.
>
> Cheers
> Serge

Welcome to teaching at the university level.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)
Received on Sat Jun 19 2004 - 13:59:42 CDT

Original text of this message

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