Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: tough choices
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.
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.
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.
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?
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.
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.
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." ;-)
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.
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