Re: tough choices

From: Michael Austin <maustin_at_firstdbasource.com>
Date: Thu, 17 Jun 2004 22:12:41 GMT
Message-ID: <tHoAc.6647$A84.4853@newssvr24.news.prodigy.com>

Niall Litchfield wrote:

> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
> news:1087421232.498660_at_yasure...
>

>>The main consideration I would think would be the overhead of federating
>>data for DB2. The more data the more difficult and time consuming and
>>the fact that losing nodes with RAC is an inconvience ... with DB2 you
>>have a lot more to worry about ... and mean time between failures goes
>>down, not up, as you add nodes.

>
>
> I'd be impressed with a RAC 'scalability' solution that didn't have higher
> downtime than an appropriately sized single node equivalent. More complexity
> = less screwups is an equation with which I am unfamiliar :) The same of
> course applies to IBM clustered solutions.
>

Daniel,

If I understand the correct programming of a RAC application is to have a connection to multiple nodes in the cluster simultaneously and if there is a failure, the transaction continues unscathed on another node in the cluster. I have seen this demonstrated to be true. So, what this should mean is that even though you may have a node crash, your application AND database AND transactions will survive with no "downtime" experienced by the end user. The application and database is available 100% or as near 100% as you can get...

According to Oracle marketing and technical folks (2 years ago), this really only worked as advertised on 2 platforms. Can you guess which ones they were??

You mentioned that you have a multi-node Linux cluster using a NAS-head for disk access... Can you provide me a pointer to the details of the complete configuration? I am not opposed to learning new configurations and platforms. What do you see as it's weaknesses and strong-points.

Michael Austin. Received on Thu Jun 17 2004 - 17:12:41 CDT