Re: tough choices

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Thu, 17 Jun 2004 22:34:46 -0700
Message-ID: <1087536907.160585@yasure>

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.

It is not the more complexity equals fewer screw-ups but rather the implications are different.

If I have a single table in a tablespace in Oracle stored in a single datafile the data is equally accessible from all nodes. Lose a node and there is no negative effect on the ability to access any part of a the data in that table. Federate the data as is required by shared nothing architectures and the loss of a single node effectively kills the system.

Thus with shared everything the more nodes the less likely a failure whereas with shared nothing loss of a node makes part of the data inaccessible.

-- 
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 Fri Jun 18 2004 - 00:34:46 CDT