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: Sun, 20 Jun 2004 08:29:49 -0700
Message-ID: <1087745414.293764@yasure>


Serge Rielau wrote:

> Daniel Morgan wrote:
>

>> Mark A wrote:
>>
>>>> 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.

>
> Daniel, you are still measures with two metrics :-)
> When an Oracle RAC node goes down it has information that is needed by
> the other nodes. All the remaining nodes are affected by that during
> this timeframe where RAC gets its balance back.

Which is sub-second. So what's the point?

> I take your word, that this is in the second ballpark.

Sub-second in my lab. And I'm not even using fast equipment like fiber.

> Now in a DB2 + DPF scenario, if DB Partition goes down all clients
> connected to that partition get kicked.

Which it would seem to me is a substantial consideration.

> All other clients will not get kicked and they may or may not feel that
> a partition went down, depending on whether the downed partition is
> needed or not.

And what are the chances that it might be needed unless you hand coded for a specific number of partitions and distribution of data which would send you back to your source code everytime you added or removed a node.

>>> Do you mean loose the database permanently or just until a fallover 
>>> can be
>>> accomplished or the hardware repaired? I don't know of a situation where
>>> data would be lost permanently unless there was a multiple disk failure
>>> affecting both the data and logs. 
>>
>> I meant only until it is brought back on-line. DB2 is far more robust to
>> become ashes ... just toast.  ;-)

>
> Right, so now the question is the race against time to get the down
> partition up again. On the same hardware, different hardware, doesn't
> matter.

Except that with RAC the SA and DBA could just ignore it until the following morning as no loss of service is involved.

> Just to wrap up:
> The point being made is:
> 1. DB2 + DPF for near unlimited scale out
> (DB2 supports 999 DB Partitions,
> there >100 partition installation out there)
> 2. DB2 + DPF _supports_ HA solutions if needed
> 3. DB2 + DPF is not an HA feature and never was meant to be one.

Thanks.

> My personal toughts on RAC are:
> Oracle RAC is an HA feature with neat limited scale out ability
> Oracle RAC has yet to proof how far it can scale out.

64 nodes with 9i and 128 nodes with 10g is the largest of which I am personally aware.

> I don't believe that near linear scale out can be achieved without a
> divide and conquer strategy of sorts. That strategy requires schema/app
> changes.

I do ... but then I've been working with it.

>
> Cheers
> Serge

-- 
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 Sun Jun 20 2004 - 10:29:49 CDT

Original text of this message

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